Hi, I have a webservice implemented as follows: | public class SSSServiceProvider implements Provider<Source> { | | @Resource(type = Object.class) | protected WebServiceContext wsContext; | | public Source invoke(Source req) { | MessageContext mc = wsContext.getMessageContext(); | String path = ((String) mc.get(MessageContext.PATH_INFO)); | .... | I'm using wsContext for the sole purpose to access a path, since my wsdl is just doc/literal (not wrapped). This code worked ok at JBoss 5.0.1 (and jbossws 3.1.0), at least i didn't notice any problems with extracted "path". Recently, we moved to JBoss 5.1.0 (jbossws 3.1.2) and problems started to appear. Under some load (~20 000 requests / day) service started to mess up injected wsContext. Some 10-100 requests per day got wrong "path", looks like it comes from the adjacent request (<~1ms incoming time). What i did then is I upgraded jbossws to 3.2.0, released recently. At first i didn't notice any errors. After a few days I decided to move other service (heavy loaded) to JBoss 5.1 + JBossws 3.2.0 as well. "Heavy-loaded" service consumes some ~1 000 000 requests / day and the same error happens now 100-300 times a day. Btw, later I found that 1st service (under ~20 000) generates the same errors as well, but at a much less rate - ~5/week. Both services are implemented virtually identically. Is it possible that next request corrupts injected wsContext object before I finish reading it??? It looks like this because as far as I see from logs it gets corrupted only if two messages are _really close_ (<~1ms). The question is - how do I get path reliably? PS. In last changelogs I see some bugfixes with resources injection, so I guess I've encountered some kind of new behaviour. PPS. I've reported the problem before (testing the same services) that might be related somehow https://jira.jboss.org/jira/browse/JBWS-2662 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262181#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...