[jBPM] - Dispose of knowledgeSession when use with persistence
by Andy Yeung
Andy Yeung [http://community.jboss.org/people/andy.yeung] created the discussion
"Dispose of knowledgeSession when use with persistence"
To view the discussion, visit: http://community.jboss.org/message/634738#634738
--------------------------------------------------------------
We are trying to use JBPM 5 with persistence to handle long workflow involving human task. I have read some other dicussion in the forum and they suggest to use 1 session for each workflow while having a single session to handle all schedule task. Session is reinitialize when handling user response like complete task such that workflow will not stucked and continue to subsequent nodes. The problem comes when the task complete.
| | | | BlockingTaskOperationResponseHandler responseHandler = new BlockingTaskOperationResponseHandler(); |
| | | | getTaskClient().complete(pTaskId, pUserId, contentData, responseHandler); |
| | | | responseHandler.waitTillDone(10000); |
| | | | knowledgeSession.dispose(); |
I found that responseHandler.waitTillDone already jump out when the complete msg successfully sent to task server.
It doesn't wait until the CommandBasedWSHumanTaskHandler task completed event to be executed.
This make the session closed and the jbpm app scope transaction manager being released and cause the transitted workflow state in CommandBasedWSHumanTaskHandler cannot be persisted.
I want to know if it's just my usage or configuration problem. It seems it require me to modify the CommandBasedWSHumanTaskHandler and let my code above to wait until CommandBasedWSHumanTaskHandler.TaskCompletedHandler to finish its job first before I dispose the session.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/634738#634738]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
[JBoss Messaging] - Possible bug with JBoss Messaging on bisocket transport
by Husgaard
Husgaard [http://community.jboss.org/people/Husgaard] created the discussion
"Possible bug with JBoss Messaging on bisocket transport"
To view the discussion, visit: http://community.jboss.org/message/634694#634694
--------------------------------------------------------------
Hi,
I am using JBoss Messaging 1.4.7.GA with the bisocket transport from JBoss Remoting 2.5.3.SP1 connecting to remote clients.
Ever since I started using this combination I have seen some stability issues on large and busy production systems that I have been unable to reproduce in a test environment. I have mostly seen these issues when the systems have been very busy, and I have noticed that these issues become a lot worse when the network is not good (high packet loss and/or parts of the network disconnecting at times).
Today I think I have found the cause of these issues, and it looks like a bug in the interface between JBoss Messaging and JBoss Remoting. I would like some of you JBoss Messaging experts here to comment on my observations before I open a JIRA ticket.
My findings starts with two thread dumps obtained at a production server experiencing these issues. The thread dumps were taken 8 seconds apart, and both show the same stack trace:
"WorkManager(2)-76" daemon prio=10 tid=0x00002aaae483c000 nid=0x3d40 in Object.wait() [0x000000004770a000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket(BisocketClientInvoker.java:528)
- locked <0x000000070f9cb8f8> (a java.util.HashSet)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:1165)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:816)
at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:461)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:167)
at org.jboss.remoting.Client.invoke(Client.java:2034)
at org.jboss.remoting.Client.invoke(Client.java:877)
at org.jboss.remoting.Client.invokeOneway(Client.java:926) - not client side, means we may block instead of executing in a new thread
at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallback(ServerInvokerCallbackHandler.java:835)
at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallbackOneway(ServerInvokerCallbackHandler.java:708) - serverSide=false
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.performDelivery(ServerSessionEndpoint.java:1467)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.handleDelivery(ServerSessionEndpoint.java:1379)
- locked <0x00000006a8c8dfd0> (a org.jboss.jms.server.endpoint.ServerSessionEndpoint)
at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:328)
- locked <0x0000000695caa390> (a java.lang.Object)
at org.jboss.messaging.core.impl.RoundRobinDistributor.handle(RoundRobinDistributor.java:119)
at org.jboss.messaging.core.impl.MessagingQueue$DistributorWrapper.handle(MessagingQueue.java:590)
at org.jboss.messaging.core.impl.ClusterRoundRobinDistributor.handle(ClusterRoundRobinDistributor.java:79)
at org.jboss.messaging.core.impl.ChannelSupport.deliverInternal(ChannelSupport.java:665)
at org.jboss.messaging.core.impl.MessagingQueue.deliverInternal(MessagingQueue.java:513)
at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:246)
- locked <0x0000000695caa498> (a java.lang.Object)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2504)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:580)
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:779)
(snip)
This thread is trying to deliver a JMS message and is waiting in BisocketClientInvoker.createSocket() for a remote client to open a connection back to the server. At the same time the thread holds a read lock in MessagingPostOffice. This means that any work in MessagingPostOffice that needs a write lock is blocked.
The problem in this case is that the remote client is no longer connected to the network, so it will never connect back to the server. The wait in BisocketClientInvoker.createSocket() will time out after some time. There is a retry loop in BisocketClientInvoker.createSocket() which will retry a few times, but eventually the call will fail and the read lock in MessagingPostOffice is released. If I read the code correctly the read lock is held for 60 seconds, if the JBoss Remoting settings are default.
Having the MessagingPostOffice lock exposed to client communication problems in this way is not good, and probably not what you want.
Looking at the way JBoss Messaging calls JBoss Remoting when delivering a message to a remote client, I see that you use one-way calls where the caller does not care about a response, and the call is executed in another thread. But in JBoss Remoting there are two way of doing this:
1. Starting a thread on the caller side to handle the call. This way the new thread will take care of any communication problems, and the calling thread can return immediately so the read lock in MessagingPostOffice is immediately released.
2. Starting a new thread on the remote side to handle the call. This way the calling thread has to take care of any communication problems, and only when the invocation has been delivered to the remote side will the remote side start a new thread to handle the call.
Unfortunately it looks like JBoss Messaging is using the last way of doing one-way calls.
So my question is: Isn't this a bug? Shouldn't we use the first way of doing one-way calls instead?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/634694#634694]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
[Beginner's Corner] - JCR xpath query
by Ming Yu
Ming Yu [http://community.jboss.org/people/my600080] created the discussion
"JCR xpath query"
To view the discussion, visit: http://community.jboss.org/message/634669#634669
--------------------------------------------------------------
Hi, I have a question regarding a jcr xpath query. Here is an example similar to the one on jboss's website:
| //element(*,my:type)[./*/*/@id=1 and ./*/*/@name='test'] |
This xpath query is equivillent to the following sql select statement:
| SELECT * FROM [my:type]
JOIN [nt:base] as nodeSet1 ON ISCHILDNODE(nodeSet1,[my:type])
JOIN [nt:base] as nodeSet2 ON ISCHILDNODE(nodeSet2,nodeSet1)
WHERE nodeSet2.id = 1 and nodeSet2.name = 'test' |
What I want to achieve is to get all entries from my:type that have a two level down childnode with id = 1 AND name = 'test'. So, these two constraints have to be met on any ONE child node.
But this query will actually do this: any two level down childnode contains id = 1 or name = 'test'. The childnode can be different childnode as long as one meets id = 1 and the other one meets name = 'test'.
How can I achive my goal with xpath query?
Thanks a lot!
Ming
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/634669#634669]
Start a new discussion in Beginner's Corner at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
