0 Replies Latest reply on Oct 26, 2009 9:35 AM by Sergey Graschenko

    WebServiceContext injected field corrupted under heavy load

    Sergey Graschenko Newbie


      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