Thanks Kris. I had planned to change the WSHumanTaskHandler as I also needed to provide deadlines/escalation/notification data while creating the task.
Vijay -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kris Verlaenen Sent: Sunday, November 15, 2009 6:46 PM To: Rules Users List; Vijay K Pandey Subject: Re: [rules-users] Drools Flow 5.1.0.M1 - Pooling of WSHumanTaskHandler and MinaTaskClient - IoSession Yes, definitely making sense. In your case, it seems like the task completion event (registered using an event listener) should not necessarily be handled by the session that created the task, but that it would be useful to have a pool of session for handling user requests and one for handling system events (like timers or task completion events). We are hoping to provide this kind of flexibility (decoupling the event registration) when providing that more generic communication between the engine and the task service. But if it makes sense for now to share the same physical connection, you can definitely tweak the WSHumanTaskHandler implementation. These work item handlers are simply the binding between the engine and the underlying service and easy to change. Kris Quoting Vijay K Pandey <[email protected]>: > Thanks Kris. I did saw the connect method and saw that it only > creates a new connection if the client is null, but my question was > more at the level of "session" (StatefulKnowledgeSession) and > MinaTaskClient creation. > > > > StatefulKnowledgeSession ksession = > JPAKnowledgeService.newStatefulKnowledgeSession( kbase, null, env ); > > ksession.getWorkItemManager().registerWorkItemHandler("Human > Task", new WSHumanTaskHandler()); > > > > So with each StatefulKnowledgeSession - we will have a new "connect". > I think pooling the WSHumanTaskHandler would not make any sense bcoz > the executeWorkItem method registers the MinaTaskClient with the > MinaTaskServer for several events. > > > > Now another main component for us is the MinaTaskClient where we will > be performing lots of operation where we won't register for any > events. In that case I think we can pool the MinaTaskClient - may be > even 1 MinaTaskClient can work for all the non registered client > operations - as MINA IoSession is thread safe, need to make sure the > IoFilter to be thread safe - but to be on better side we can pool > MinaTaskClient. > > > > I hope I am making some sense? Do let me know your recommendation. > > > > Thanks > > Vijay > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Kris > Verlaenen > Sent: Sunday, November 15, 2009 1:47 PM > To: Rules Users List; Vijay K Pandey > Subject: Re: [rules-users] Drools Flow 5.1.0.M1 - Pooling of > WSHumanTaskHandler and MinaTaskClient - IoSession > > > > One WSHumanTaskHandler should cache the client, so that it does not > > recreate a new connection every time. Note that, in the connect() > > method, you only create a new connection if the client is null. > > > > Kris > > > > Quoting Vijay K Pandey <[email protected]>: > > > > > Hi, > > > > > > We have a web based application that currently deals with MQ > Workflow > > > for all the WSHT related processes/tasks. We are in the process of > > > migrating to Drools Flow. In our current scenario we pool MQ > workflow > > > session (through apache commons pooling) - and our hundreds of web > > > users use these sessions to get their word done (like starting a > new > > > process, retrieving a task, complete/forwarding/terminating tasks > > > etc) - what we have seen is that in an 8hr window we have around > > > 20,000 calls to mq workflow (around 42 calls/minute) - and it > scales > > > pretty good with mq workflow session pooling in place. > > > > > > Should I go ahead and extend WSHumanTaskHandler and MinaTaskClient > so > > > that they don't go through "connect" on every operation and get > the > > > MINA IoSession from some pool - as it might consume quite a bit of > > > resources/time consuming to have a separate physical connections > for > > > each operation. > > > > > > Looking forward for your recommendations. > > > > > > Thanks > > > Vijay > > > > > > > > > > > > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm > > _______________________________________________ > > rules-users mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/rules-users > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
