1 Reply Latest reply on Aug 15, 2011 7:55 AM by Mauricio Salatino

    CommandBasedWSHumanTaskHandler session, client ???

    Gary Struthers Newbie

      To persist a session, I'm trying to use CommandBasedWSHumanTaskHandler in code based on Salaboy's PersistentProcessManager and TaskClientHelper with Mina

       

          private StatefulKnowledgeSession getKnowledgeSession() {

              StatefulKnowledgeSession ksession = null;

              if (ksessionId == null) {

       

                  ksession = JPAKnowledgeService.newStatefulKnowledgeSession(

                          kbase,

                          null,

                          env);

       

                  ksessionId = ksession.getId();

              } else {

                  ksession = JPAKnowledgeService.loadStatefulKnowledgeSession(

                          ksessionId,

                          kbase,

                          null,

                          env);

              }

       

                  humanActivitiesHandler = new CommandBasedWSHumanTaskHandler(ksession);

                                    humanActivitiesHandler.setClient(TaskClientHelper.getInstance().taskClient);

                  this.workItemsHandlers.put("Human Task", humanActivitiesHandler);

       

              for (Map.Entry<String, WorkItemHandler> entry : this.workItemsHandlers.entrySet()) {

                  ksession.getWorkItemManager().registerWorkItemHandler(entry.getKey(), entry.getValue());

              }

       

              //Configures a logger for the session

              KnowledgeRuntimeLoggerFactory.newConsoleLogger(ksession);

       

              return ksession;

          }

       

      The handler only accepts a session in the constructor so I guess I'm supposed to construct one every time I get a session from the database and then hope resisterWorkItem works correctly. This doesn't look good. I wish I could create the handler once and then bind it to a session when I have one. I don't know if creating these handlers is idempotent. Then I tried exposing the TaskClient and passing it to the new handler.

       

      Inside the handler the connect method creates a WSHumanTaskHandler. This looks like a bug. 

      public class CommandBasedWSHumanTaskHandler implements WorkItemHandler {

      ...

      public void connect() {

      if (client == null) {

      client = new TaskClient(new MinaTaskClientConnector("org.drools.process.workitem.wsht.WSHumanTaskHandler",

      new MinaTaskClientHandler(SystemEventListenerFactory.getSystemEventListener())));

      boolean connected = client.connect(ipAddress, port);

       

      if (!connected) {

      throw new IllegalArgumentException("Could not connect task client");

      }

      }

        • 1. Re: CommandBasedWSHumanTaskHandler session, client ???
          Mauricio Salatino Master

          Hi Gary,

          I think that you find the reason why you need to create the handlers and register them each time that. Runtime Handlers are not persisted with the session information, that means that each time that you load the session you need to re-register them in order to be sure that they will work for that runtime session. If you create a new Handler, the session is persisted and another thread or JVM loads the session persistend in the database the handler cannot be shared.

           

          I'm right now changing the code inside the TaskHandlers to improve it, but as you can see, the handler contains a task client that as soon as its created it tryies to reach a Human Task server. Mina was the first transport supported and now that we support a couple of them + the local implementation this code needs to be changed a little bit. As I mention, I'm working on that now and I hope to get it done for tomorrow.

           

          Cheers