6 Replies Latest reply on Apr 22, 2014 3:42 AM by jinalu

    jbpm5 timer and process recovery

    jinalu

      Hi,

      I have the question about jbpm timer specifics. In my case I have jbpm process running drools guvnor and for some steps custom handlers are used (running on servicemix). The handler I have problem with is called after timer and it call webservice client (object injected using spring).

      In normal scenario everything goes fine, but if I refresh in servicemix installed bundle when process instance is in timer step I'm getting "java.lang.IllegalStateException: The client has been closed. at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:96)" when executing step after timer. My process:

      Step 1 -> Step 2 ->  Timer -> Ws calling handler step -> End

      If handlers suorce update is done when the process is running step 2 everything is fine. So I'm guessing my problem is somehow related to timer execution specifics. Maybe timer is somehow holding destroyed session or it is related to process persistence specifics? Please help.

        • 1. Re: jbpm5 timer and process recovery
          swiderski.maciej

          most likely the problem is in the handler that calls the web service as timer has nothing to do with it. What might be the cause is that handler in caching the web service client and thus this exception.

           

          HTH

          • 2. Re: jbpm5 timer and process recovery
            jinalu

            Thank you for the answer. How should I check if handler is caching the web service client? As you see I didn't defined any caching myself:

            <bean id="myHandler"  class="myproject.MyHandler">

                    <property name="myWsClient" ref="myWsClient" />

            </bean>

             

            <jaxws:client id="myWsClient"

                    serviceClass=myproject.WsServices" address="${myWsClient.proxyUrl}">

                    <jaxws:properties>

                        <entry key="ws-security.username" value="${myWsClient.user}" />

                        <entry key="ws-security.password" value="${myWsClient.password}" />

                    </jaxws:properties>

                    <jaxws:features>

                        <p:policies>

                            <wsp:PolicyReference

                                URI="classpath:/META-INF/ws-policy/usernameToken.xml" />

                        </p:policies>

                    </jaxws:features>

            </jaxws:client>

            • 3. Re: jbpm5 timer and process recovery
              swiderski.maciej

              looks like this class myproject.MyHandler is caching (or keeping reference to the client) so you need to make sure that whenever it is not valid anymore, you'll get new instance or somehow refresh existing one.

               

              HTH

              • 4. Re: jbpm5 timer and process recovery
                jinalu

                Hi,

                Thank you for the suggestions. Unfortunately I'm still unlucky trying to solve this issue. I checked my service mix bundle - no caching is set for the spring bean. Maybe drools (v5.5) cache the instance? Could be any caching of class instance there and if is where should I check?

                I also was thinking about recreating myWsClient object, but still figuring out how to do that.

                I would really appreciate any help or guidance

                 

                Added:

                Figured out that after the restart of bundle the same instance of Handler is used despite the fact that it had to be already destroyed. How I could affect that, to have new instance with newly loaded objects?

                • 5. Re: jbpm5 timer and process recovery
                  swiderski.maciej

                  I guess handler might be the same instance just make sure that the logic in it can deal with problems, for example when there is certain type of exception recreate the WS client.

                   

                  Since handler and other instance are created by spring container then you need to check why these instances are kept across bundle restarts.

                   

                  HTH

                  • 6. Re: jbpm5 timer and process recovery
                    jinalu

                    Maciej, could you provide more detail how to check why old instances are kept across after restarts? I think it is somehow related to the jbpm timer intermediate event specifics, but I don't know exactly. I'm new to drools and all this jbpm and service mix staff. Maybe you could explain how the timer works related to ksession? Does timer start separate thread and it might be unaware about spring session change and uses old context in executing next steps?

                    Also about the WS proxy client recreation could you provide any information where I could read about how to do that correctly?