Hello sebb, Regarding: > 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.
If it was the case then there was an issue in this, because 2 threads could share the same Context in initial implementation. Maybe an issue with perf, I will add thread name to key Regards On Wed, Oct 19, 2011 at 8:02 AM, sebb <seb...@gmail.com> wrote: > > On 18 October 2011 22:21, sebb <seb...@gmail.com> wrote: > > On 18 October 2011 19:50, Philippe Mouawad > > <p.moua...@ubik-ingenierie.com> 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_MorphoTrak; > >> > >> 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 many > >> 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 performances > >> if not cached ? > > > > I think that was before my time. > > > >> There are 2 solutions for that: > >> > >> - We remove caching > >> - We add an option in GUI to let user select if Context will be cached > >> 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. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > -- Cordialement. Philippe Mouawad.
