Re: Issue 52044
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
Issue 52044
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.
Re: Issue 52044
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. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org