[JBoss Messaging Users] - After migrating from JBossMQ to JBM:
by the_olo
Hi!
After migrating from JBoss MQ to JBoss Messaging (which also required deploying the relevant queues manually), our installation of jBPM-BPEL has started throwing the following exception in the logs:
2009-10-01 12:51:46,648 ERROR [org.jboss.jms.client.container.ClosedInterceptor] ClosedInterceptor.ClientSessionDelegate[46-n2vsd90g-1-2wuqd90g-x8tmkt-100j3]:
| method postDeliver() did not go through, the interceptor is CLOSED
| 2009-10-01 12:51:46,648 ERROR [org.jboss.jms.client.container.ClientConsumer] Failed to deliver message
| javax.jms.IllegalStateException: The object is closed
| at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:157)
| at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$postDeliver_1255239194451907669.invokeNext(ClientSessionDelegate$postDeliver_125523919445190766
| 9.java)
| at org.jboss.jms.client.delegate.ClientSessionDelegate.postDeliver(ClientSessionDelegate.java)
| at org.jboss.jms.client.container.ClientConsumer.callOnMessage(ClientConsumer.java:253)
| at org.jboss.jms.client.container.ClientConsumer$ListenerRunner.run(ClientConsumer.java:1043)
| at org.jboss.messaging.util.OrderedExecutorFactory$ChildExecutor.run(OrderedExecutorFactory.java:120)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
| at java.lang.Thread.run(Thread.java:595)
This is thrown after the SOAP response is sent back to the client, at the end of BPEL process execution, so it doesn't seem to influence its correct outcome. However, I'm afraid of any side effects (e.g. performance issues, rolled back XA transactions?).
One more symptom that I've observed is that message counters on the queues aren't incremented in queue MBeans (name=JbpmCommandQueue,service=Queue and name=JbpmJobQueue,service=Queue) - I think it could be related to this exception.
Here's how the queue MBeans are configured for jBPM-BPEL:
| <?xml version="1.0" encoding="UTF-8"?>
| <server>
| <mbean code="org.jboss.jms.server.destination.QueueService"
| name="jboss.messaging.destination:service=Queue,name=JbpmCommandQueue"
| xmbean-dd="xmdesc/Queue-xmbean.xml">
| <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
| <depends>jboss.messaging:service=PostOffice</depends>
| </mbean>
| <mbean code="org.jboss.jms.server.destination.QueueService"
| name="jboss.messaging.destination:service=Queue,name=JbpmJobQueue"
| xmbean-dd="xmdesc/Queue-xmbean.xml">
| <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
| <depends>jboss.messaging:service=PostOffice</depends>
| </mbean>
| </server>
|
Any ideas what might cause the problem?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258110#4258110
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258110
16 years, 7 months
[Clustering] - Cluster falls apart: FD_SOCK errors
by kennardconsulting
Guys,
We are seeing these warnings on our cluster nodes sometimes after a redeploy. The primary cluster node stays up,
but the other 2 (we have 3) die and keep saying this.
2009-10-01 20:04:34,302 main WARN [org.jgroups.protocols.pbcast.GMS] join(192.168.1.2:37802) sent to 192.168.1.1:52187 timed out (after 3000 ms), retrying
| 2009-10-01 20:04:37,315 main WARN [org.jgroups.protocols.pbcast.GMS] join(192.168.1.2:37802) sent to 192.168.1.1:52187 timed out (after 3000 ms), retrying
| 2009-10-01 20:04:40,318 main WARN [org.jgroups.protocols.pbcast.GMS] join(192.168.1.2:37802) sent to 192.168.1.1:52187 timed out (after 3000 ms), retrying
| 2009-10-01 20:04:43,321 main WARN [org.jgroups.protocols.pbcast.GMS] join(192.168.1.2:37802) sent to 192.168.1.1:52187 timed out (after 3000 ms), retrying
| 2009-10-01 20:04:46,323 main WARN [org.jgroups.protocols.pbcast.GMS] join(192.168.1.2:37802) sent to 192.168.1.1:52187 timed out (after 3000 ms), retrying
| 2009-10-01 20:04:49,326 main WARN [org.jgroups.protocols.pbcast.GMS] join(192.168.1.2:37802) sent to 192.168.1.1:52187 timed out (after 3000 ms), retrying
| 2009-10-01 20:04:52,329 main WARN [org.jgroups.protocols.pbcast.GMS] join(192.168.1.2:37802) sent to 192.168.1.1:52187 timed out (after 3000 ms), retrying
| 2009-10-01 20:04:55,332 main WARN [org.jgroups.protocols.pbcast.GMS] join(192.168.1.2:37802) sent to 192.168.1.1:52187 timed out (after 3000 ms), retrying
They keep saying this even after a restart. Only restarting the primary node fixes things. We can see 192.168.1.1:52187 is listening on the primary with netstat -panu
On that server, the logs say
192.168.1.2:37802 ERROR [org.jgroups.protocols.FD_SOCK] socket address for 192.168.1.2:37802 could not be fetched, retrying.
However, on the 192.168.1.2 box, we can see 192.168.1.2:37802 is also listening.
We can ping and telnet to tcp ports on both boxes and between each box, and ipconfig shows no packet losses, collisions or other
networking errors. Also a restart of JBoss on the primary fixes the problem.
Therefore the problem seems to be something within JBoss.
On the primary server there are a number of threads referring to port 52187 and none of these seem locked up (as far as I can see).
Here are some of the threads from the Primary:
This looks like the server socket:
"FD_SOCK server socket acceptor,192.168.1.1:52187" daemon prio=10 tid=0x0ac19800 nid=0x6281 runnable [0x66293000]
| java.lang.Thread.State: RUNNABLE
| at java.net.PlainSocketImpl.socketAccept(Native Method)
| at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:390)
| - locked <0xab976ea0> (a java.net.SocksSocketImpl)
| at java.net.ServerSocket.implAccept(ServerSocket.java:453)
| at java.net.ServerSocket.accept(ServerSocket.java:421)
| at org.jgroups.protocols.FD_SOCK$ServerSocketHandler.run(FD_SOCK.java:1022)
| at java.lang.Thread.run(Thread.java:619)
This looks like the connection handler:
"FD_SOCK client connection handler,AvantProduction,192.168.1.1:52187" daemon prio=10 tid=0x097e8000 nid=0x1a6c runnable [0x62c
| 71000]
| java.lang.Thread.State: RUNNABLE
| at java.net.SocketInputStream.socketRead0(Native Method)
| at java.net.SocketInputStream.read(SocketInputStream.java:129)
| at java.net.SocketInputStream.read(SocketInputStream.java:182)
| at org.jgroups.protocols.FD_SOCK$ClientConnectionHandler.run(FD_SOCK.java:1089)
| at java.lang.Thread.run(Thread.java:619)
And these are threads waiting in a pool by the look of it:
"Incoming-14,192.168.1.1:52187" prio=10 tid=0x091c9400 nid=0x5f7f waiting on condition [0x68e1f000]
| java.lang.Thread.State: WAITING (parking)
| at sun.misc.Unsafe.park(Native Method)
| - parking to wait for <0x8b246af0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
| at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
| at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
| at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
| at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
| at java.lang.Thread.run(Thread.java:619)
|
| "Incoming-13,192.168.1.1:52187" prio=10 tid=0x091c7c00 nid=0x5f7e waiting on condition [0x68e70000]
| java.lang.Thread.State: WAITING (parking)
| at sun.misc.Unsafe.park(Native Method)
| - parking to wait for <0x8b246af0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
| at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
| at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
| at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
| at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
| at java.lang.Thread.run(Thread.java:619)
Here is a list of all threads referring to port 52187:
"VERIFY_SUSPECT.TimerThread,AvantProduction-HAPartitionCache,192.168.1.1:52187" daemon prio=10 tid=0x0b838400 nid=0x1d9d waiting on condition [0x5f1fe000]
| "OOB-680,192.168.1.1:52187" prio=10 tid=0x73163400 nid=0x1d9c waiting on condition [0x66c48000]
| "OOB-678,192.168.1.1:52187" prio=10 tid=0x6ef51800 nid=0x1c8e waiting on condition [0x66a62000]
| "FD_SOCK client connection handler,AvantProduction,192.168.1.1:52187" daemon prio=10 tid=0x097e8000 nid=0x1a6c runnable [0x62c71000]
| "FD_SOCK pinger,AvantProduction-HAPartitionCache,192.168.1.1:52187" daemon prio=10 tid=0x092ba400 nid=0x69b7 waiting on condition [0x5f15c000]
| "ViewHandler,AvantProduction-HAPartitionCache,192.168.1.1:52187" prio=10 tid=0x0c48d400 nid=0x6506 waiting on condition [0x5f1ad000]
| "FD_SOCK server socket acceptor,192.168.1.1:52187" daemon prio=10 tid=0x0ac19800 nid=0x6281 runnable [0x66293000]
| "Incoming-20,192.168.1.1:52187" prio=10 tid=0x71df4400 nid=0x5f8d waiting on condition [0x68a02000]
| "Incoming-19,192.168.1.1:52187" prio=10 tid=0x091ed400 nid=0x5f89 waiting on condition [0x68b46000]
| "Incoming-18,192.168.1.1:52187" prio=10 tid=0x7161dc00 nid=0x5f88 waiting on condition [0x68b97000]
| "Incoming-17,192.168.1.1:52187" prio=10 tid=0x091ecc00 nid=0x5f84 waiting on condition [0x68c8a000]
| "Incoming-16,192.168.1.1:52187" prio=10 tid=0x72a4a800 nid=0x5f83 waiting on condition [0x68cdb000]
| "Incoming-15,192.168.1.1:52187" prio=10 tid=0x091ca400 nid=0x5f80 waiting on condition [0x68dce000]
| "Incoming-14,192.168.1.1:52187" prio=10 tid=0x091c9400 nid=0x5f7f waiting on condition [0x68e1f000]
| "Incoming-13,192.168.1.1:52187" prio=10 tid=0x091c7c00 nid=0x5f7e waiting on condition [0x68e70000]
| "Incoming-12,192.168.1.1:52187" prio=10 tid=0x08f7ec00 nid=0x5f7d waiting on condition [0x68ec1000]
| "Incoming-11,192.168.1.1:52187" prio=10 tid=0x6d3f8400 nid=0x5f7c waiting on condition [0x68f12000]
| "Incoming-10,192.168.1.1:52187" prio=10 tid=0x091c5800 nid=0x5f7b waiting on condition [0x68f63000]
| "Incoming-9,192.168.1.1:52187" prio=10 tid=0x713f5800 nid=0x5f7a waiting on condition [0x68fb4000]
| "Incoming-8,192.168.1.1:52187" prio=10 tid=0x09cbe000 nid=0x5f79 waiting on condition [0x69005000]
| "Timer-12,192.168.1.1:52187" daemon prio=10 tid=0x713e5800 nid=0x5f78 waiting on condition [0x69056000]
| "Timer-11,192.168.1.1:52187" daemon prio=10 tid=0x6cdf8800 nid=0x5f77 waiting on condition [0x690a7000]
| "Timer-10,192.168.1.1:52187" daemon prio=10 tid=0x71471c00 nid=0x5f75 waiting on condition [0x69149000]
| "Incoming-7,192.168.1.1:52187" prio=10 tid=0x09cbac00 nid=0x5f74 waiting on condition [0x6919a000]
| "Incoming-6,192.168.1.1:52187" prio=10 tid=0x08f7f800 nid=0x5f72 waiting on condition [0x6923c000]
| "Timer-9,192.168.1.1:52187" daemon prio=10 tid=0x08d8a800 nid=0x5f71 waiting on condition [0x6928d000]
| "Timer-8,192.168.1.1:52187" daemon prio=10 tid=0x08fd1000 nid=0x5f6f waiting on condition [0x6932f000]
| "Timer-7,192.168.1.1:52187" daemon prio=10 tid=0x0927f800 nid=0x5f6d waiting on condition [0x693d1000]
| "Incoming-5,192.168.1.1:52187" prio=10 tid=0x091ae800 nid=0x5f6c waiting on condition [0x69422000]
| "Incoming-4,192.168.1.1:52187" prio=10 tid=0x091ad400 nid=0x5f6b waiting on condition [0x69473000]
| "Incoming-3,192.168.1.1:52187" prio=10 tid=0x08e98800 nid=0x5f6a waiting on condition [0x694c4000]
| "Incoming-2,192.168.1.1:52187" prio=10 tid=0x08e97800 nid=0x5f69 waiting on condition [0x69515000]
| "Incoming-1,192.168.1.1:52187" prio=10 tid=0x08ee5800 nid=0x5f68 waiting on condition [0x69566000]
| "Timer-6,192.168.1.1:52187" daemon prio=10 tid=0x717d2800 nid=0x5f67 waiting on condition [0x695b7000]
| "Timer-5,192.168.1.1:52187" daemon prio=10 tid=0x712ff000 nid=0x5f66 waiting on condition [0x69608000]
| "Timer-4,192.168.1.1:52187" daemon prio=10 tid=0x711fd800 nid=0x5f64 waiting on condition [0x696aa000]
| "Timer-3,192.168.1.1:52187" daemon prio=10 tid=0x09297800 nid=0x5f62 waiting on condition [0x696fb000]
| "Timer-2,192.168.1.1:52187" daemon prio=10 tid=0x090a6800 nid=0x5f5f waiting on condition [0x697ee000]
| "UDP mcast,192.168.1.1:52187" prio=10 tid=0x09956c00 nid=0x5f5e runnable [0x6983f000]
| "UDP ucast,192.168.1.1:52187" prio=10 tid=0x09956800 nid=0x5f5d runnable [0x69890000]
| "DiagnosticsHandler,192.168.1.1:52187" daemon prio=10 tid=0x08ee6c00 nid=0x5f5c runnable [0x698e1000]
| "Timer-1,192.168.1.1:52187" daemon prio=10 tid=0x08e56c00 nid=0x5f5a waiting on condition [0x69983000]
This is really hurting our up-time. Could anybody point us in the right direction?
Regards,
Richard.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258102#4258102
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258102
16 years, 7 months
[JBoss Remoting Users] - Re: No ping on secondaryBindPort
by enriqueam
Hello Ron,
Thank you for your quick response!
I have downloaded Remoting release 2.2.3.SP1 and replace the existing one in my standalone client and in JBoss As 4.2.3.GA server's libs (in the server configuration for JBoss Messaging 1.4.4.GA)
I have configured remoting-bisocket-service.xml with the attribute values you suggest and have also added the attribute
<attribute name="DisableRemotingChecks">true</attribute>
to connection-factories-service.xml to make sure Messaging accepts the changes in those immutable attributes.
Still no luck. The firewall does not timeout primary port 4457 because there is a ping between client and server. However, the ServerThread running on the client blocks on the secondary bind port, fixed to value 4458, to read the version, as shown in trace line
56411 [WorkerThread#0[192.168.6.1:4458]] TRACE org.jboss.remoting.transport.socket.ServerThread - blocking to read version from input stream
The problem is that if no message is sent, the firewall times out that port and not 4457. Upon a new message is posted on the topic after the port 4458 has timed out at the firewall, the messages is received by the client and then the client and server detects a problem on port 4458. However, the client does not scale the exception to the Messaging ExceptionListener. Instead, it logs out the exception, and just keeps pinging the server on port 4457, which completes successfully every time. As I said, the ServerThread working on port 4458 gets stuck on a call to wait().
>From that point on, when a new message is posted on the queue, the client does not receive it.
Should Remoting be informing JBM of the problem if I'm using generalizeSockeException?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258094#4258094
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258094
16 years, 7 months
[JBoss Cache Users] - Re: What is an invocation, and the related option override?
by mircea.markus
it only makes sense to use setForceWriteLock(true) on read. Normally when you do an cache.get(fqn) an read lock is aquired, but setting the forceWriteLock to true would force a write lock acquisition. when you do a put(fqn)(generally a write), a WL (write lock) is acquired so having the flag is redundant. As a general rule, the forceWriteLock only apply for one call, i.e. for one invocation.
tm.begin();
| // force write lock even on read operations
| cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true);
|
| // read node
| Object value = cache.get(myFqn, "key");
|
| Object value = cache.get(myFqn2, "key");
|
| tm.commit();
In this example a WL is acquired for myFqn and a RL is acquired for myFqn2
anonymous wrote : In other words, once I set the "setForceWriteLock(true)", all future cache related operations in this thread will see this option set to "true". No. Only the next call, after that the flag is cleaned. As mentioned in the previous post, an invocation is an call to the cache.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258093#4258093
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258093
16 years, 7 months
[jBPM Users] - Re: BPEL 1.1GA: CodeSource for SOAPMessage is NULL
by prachi.mukhija
Hi,
I am pretty new to jbpm-bpel. I have downloaded the jbpm-bpel-1.1.1 version.
My envrironment is:
jboss-4.2.2.GA server
However, I am facing the same error when deploying "Hello" example.
Here's the stack trace.
| 15:31:26,746 INFO [DeploymentServlet] deployed process definition: HelloWorld
| 15:31:26,846 ERROR [[deploymentServlet]] Servlet.service() for servlet deploymentServlet threw exception
| java.lang.NullPointerException
| at org.jbpm.bpel.tools.WscompileTool.getLocation(WscompileTool.java:240)
| at org.jbpm.bpel.tools.WscompileTool.formatClasspath(WscompileTool.java:227)
| at org.jbpm.bpel.tools.WscompileTool.callWscompile(WscompileTool.java:197)
| at org.jbpm.bpel.tools.WscompileTool.generateJavaMappingImpl(WscompileTool.java:156)
| at org.jbpm.bpel.tools.WscompileTool.generateJavaMapping(WscompileTool.java:143)
| at org.jbpm.bpel.tools.WebModuleBuilder.callJavaMappingTool(WebModuleBuilder.java:264)
| at org.jbpm.bpel.tools.WebModuleBuilder.buildModuleImpl(WebModuleBuilder.java:102)
| at org.jbpm.bpel.tools.WebModuleBuilder.buildModule(WebModuleBuilder.java:84)
| at org.jbpm.bpel.web.DeploymentServlet.deployWebModule(DeploymentServlet.java:205)
| at org.jbpm.bpel.web.DeploymentServlet.doPost(DeploymentServlet.java:99)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
| at java.lang.Thread.run(Unknown Source)
|
Please help out. Any hint would be grateful.
Thanks in advance.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258090#4258090
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258090
16 years, 7 months