Re: Issue 52044

sebb <[email protected]> Wed, 19 Oct 2011 07:02:29 +0100
Newsgroups gmane.comp.jakarta.cactus.devel
Message-ID <CAOGo0VZhLfXQOTT3LZ7ui7NpuEQODq+5FRXVWkaChiE_ptRf1Q@mail.gmail.com>
On 18 October 2011 22:21, sebb <[email protected]> wrote:
> On 18 October 2011 19:50, Philippe Mouawad
> <[email protected]> wrote:
>> Hello Sebb, Milamber , All,
>> I investigated this issue, particularly this part of issue
>>
>>> stramge error for "JMS Subscriber - 001" - Response message:
>>> javax.naming.NamingException: Something already bound at Elite_To_Morph=
oTrak;
>>
>> I created a simple test case and tried not to cache Context and it works
>> fine.
>> and in fact it is due to the fact that we cache Context and use it by ma=
ny
>> threads.
>> From this:
>> http://download.oracle.com/javase/jndi/tutorial/beyond/misc/sync.html
>>
>> I conclude we should not do caching as it is not mandatory that context =
is
>> Thread Safe (and it's not the case for AMQ one).
>>
>> Do you remember why Context were cached ? was it because of bad performa=
nces
>> if not cached ?
>
> I think that was before my time.
>
>> There are 2 solutions for that:
>>
>> =A0 - We remove caching
>> =A0 - We add an =A0option in GUI to let user select if Context will be c=
ached
>> =A0 or not
>
> Or we cache per thread, e.g. using ThreadLocal.

I've just realised there is a reason why the Context was being cached.

The Context holds execution context, so needs to be maintained between
samplers in the same thread.

One easy way to fix the context sharing across threads would be to
include the thread name in the context key.