james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [JSieve] Sporadic Mysterious Exceptions
Date Thu, 09 Aug 2007 16:42:51 GMT
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).

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.

Stefano


---------------------------------------------------------------------
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