Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <32881147.1187189611054.JavaMail.jira@brutus>
Date: Wed, 15 Aug 2007 07:53:31 -0700 (PDT)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Commented: (FELIX-338) Framework FilterImpl is not thread
 safe on execution
In-Reply-To: <15660337.1187157210406.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/FELIX-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519986 ] 

Felix Meschberger commented on FELIX-338:
-----------------------------------------

I have to admit, that I never touched ThreadLocals myself upto now. But It seems to be the best of all possibilities to fix the issues.

On the other hand, looking at the code, it seems like the Evaluator basically just ist a single method whose only data modified during evaluation is the operand stack. So, I assume, the Evaluator.evaluate(Mapper) method might just as well be copied to the FilterImpl class and the operand stack a variable local to the method - this stack would be recreated on each call (instead of the Evaluator) and need not be cleared at the end, as this is left to the GC.

The other object - the mapper - is just a facade to the actual data being used for filter matching.

So besides just not reusing the instances, I would also redo the implementation.

> Framework FilterImpl is not thread safe on execution
> ----------------------------------------------------
>
>                 Key: FELIX-338
>                 URL: https://issues.apache.org/jira/browse/FELIX-338
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 0.8.0, 1.0.0
>            Reporter: Felix Meschberger
>         Attachments: filter.patch
>
>
> Executing a Filter implemented by the Felix Framework FilterImpl class is not thread safe, as the Filter.Implmatch() methods are not synchronized but use a Mapper and Evaluator instance fields which are modified while matching the filter.
> Two options seem to exist:
>    1. Make the match() methods synchronized
>    2. Create Mapper and Evaluator instances on each match() call
> My assumption is that the second method tends to be better because of the synchronization needed with the first approach.
> Reported by Tom Remoleur, thanks. The full mail thread leading to this issue may be found at [1].
> [1] http://www.mail-archive.com/users@felix.apache.org/msg00145.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.