james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [JSieve] Sporadic Mysterious Exceptions
Date Thu, 09 Aug 2007 17:42:17 GMT
On 8/9/07, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On 8/9/07, Stefano Bagnara <apache@bago.org> wrote:
> >> Stefano Bagnara ha scritto:
> >>> /**
> >>>  * Method execute executes a Block within the context of a new
> >>> ConditionManager.
> >>>  * @param mail
> >>>  * @param block
> >>>  * @return Object
> >>>  * @throws SieveException
> >>>  */
> >>> protected Object execute(MailAdapter mail, Block block) throws
> >>> SieveException {
> >>>   // Switch to a new ConditionManager
> >>>   ConditionManager oldManager = ConditionManager.getInstance();
> >>>   ConditionManager.resetInstance();
> >>>
> >>>   // Execute the Block
> >>>   Object result = block.execute(mail);
> >>>
> >>>   // Restore the old ConditionManager
> >>>   ConditionManager.setInstance(oldManager);
> >>>
> >>>   return result;
> >>> }
> >>>
> >>> I don't get how it works. ConditionManager.resetInstance will set the
> >>> static thread local fieldInstance to null: doesn't this invalidate also
> >>> instances of every other thread using the ConditionManager ? Shouldn't
> >>> resetInstance simply remove the conditionManager from the fieldInstance
> >>> ThreadLocal  using a fieldInstance.set(null) ?
> >> Forgot to say that if this is the case it should be pretty easy to
> >> create a test case to prove it.
> >
> > how would you approach the management of the multiple threads?
>
> I'm writing the code in thunderbird, so forget syntax and other
> problems. Hope you get the idea:
>
> void testIssue() {
> ConditionManager instance1 = ConditionManager.getInstance();
>
> Thread otherThread = new Thread() {
>         public void run() {
>                 ConditionManager.resetInstance();
>         }
> }.start();
>
> otherThread.join();
>
> assertEquals(instance1, ConditionManager.getInstance());
> }
>
> otherwise, instead of checking the ConditionManager methods directly we
> could check the call to the AbstractConditionalCommand.execute.
>
> get the manager, get the condition manager instance, run the execute in
> the main thread, run the execute of another thread using the same
> pattern above, check the condition manager instance (it has to be the
> same again).

that'd probably do it

> Of course this simply prove this issue and does not check for every
> synchronization error, but I find it useful to prove bugs with tests and
> see them greened by the patch.

true

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message