[jboss-user] [JBoss Messaging Users] - Re: After migrating from JBossMQ to JBM:
BTW, some instances of this exception are accompanied by message delivery failures: 2009-10-06 12:42:20,704 WARN [org.jboss.jms.client.container.ClientConsumer] Timed out waiting for last delivery 1 got 0 | 2009-10-06 12:42:20,709 ERROR [org.jboss.jms.client.container.ClosedInterceptor] ClosedInterceptor.ClientSessionDelegate[1q1-nuttig0g-1-i1bc6f0g-oiap2t-100j3] | : method postDeliver() did not go through, the interceptor is CLOSED | 2009-10-06 12:42:20,709 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) The delivery failure occurs after a 30 second timeout from the moment the message had been sent. This isn't harmless anymore, as it causes 30 second long process executions and then failure sent back to the client. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4258849#4258849 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4258849 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Messaging Users] - After migrating from JBossMQ to JBM:
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=ServerPeerjboss.messaging:service=ServerPeer/depends | dependsjboss.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=ServerPeerjboss.messaging:service=ServerPeer/depends | dependsjboss.messaging:service=PostOffice/depends | /mbean | /server | Any ideas what might cause the problem? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4258110#4258110 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4258110 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Messaging Users] - Re: Issue with WebFileMDB
Could you share what was the problem and how did yo fix it? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4257887#4257887 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4257887 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache Users] - Re: JBoss 4.2.2 with TreeCache 1.4.1.SP5: nodes, attributes
OK, I've found the solution to my problem. First, it wasn't in the configuration of the TreeCache itself, but of the Hibernate Cache provider. It turns out that this behaviour is by design the default in the Hibernate JBoss Cache provider (hibernate-jbc-cacheprovider-1.0.1.GA.jar). See: http://www.jboss.org/community/wiki/NewJBossCache14xBasedHibernate32CacheProvider. The option responsible for this behaviour is hibernate.treecache.local_puts_only: anonymous wrote : The aim of this property, whose default value is true, is to makes sure any put calls on the Second Level Cache as a result of a read operation from the database are done locally which means that data read from database is not replicated to other nodes. So placing the following line in my hibernate.cfg.xml has enabled full cache replication across the cluster: property name=hibernate.treecache.local_puts_onlyfalse/property | The relevant portion of my Hibernate session factory configuration now looks like this: property name=hibernate.cache.provider_classorg.jboss.hibernate.jbc.cacheprovider.JmxBoundTreeCacheProvider | /property | property name=hibernate.treecache.mbean.object_namejboss.cache:service=MyTreeCache/property | property name=hibernate.treecache.local_puts_onlyfalse/property | property name=hibernate.cache.use_second_level_cachetrue/property | property name=hibernate.cache.use_query_cachefalse/property | | !-- Tuning -- | property name=hibernate.jdbc.batch_size32/property | property name=hibernate.jdbc.fetch_size32/property | property name=hibernate.default_batch_fetch_size32/property | property name=hibernate.jdbc.batch_versioned_datatrue/property View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4256600#4256600 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4256600 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache Users] - Re: JBoss 4.2.2 with TreeCache 1.4.1.SP5: nodes, attributes
What's very curious is the fact that logs on both cluster nodes indicate that the elements are added to the cache. E.g., after the BPEL process is executed and transaction gets committed: node 1 (initiator): | 2009-09-22 15:56:04,686 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/ProcessInstance/org.jbpm.graph.exe.ProcessInstance#15967 for a node that doesn't exist yet. Process as an add. | 2009-09-22 15:56:04,686 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/Token/org.jbpm.graph.exe.Token#15969 for a node that doesn't exist yet. Process as an add. | 2009-09-22 15:56:04,686 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/Token/org.jbpm.graph.exe.Token#15971 for a node that doesn't exist yet. Process as an add. | 2009-09-22 15:56:04,686 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/Token/org.jbpm.graph.exe.Token#15972 for a node that doesn't exist yet. Process as an add. | 2009-09-22 15:56:04,686 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/Token/org.jbpm.graph.exe.Token#15973 for a node that doesn't exist yet. Process as an add. | 2009-09-22 15:56:04,686 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/Token/org.jbpm.graph.exe.Token#15974 for a node that doesn't exist yet. Process as an add. | node 2 (acceptor): | 2009-09-22 15:56:03,536 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/ProcessInstance/org.jbpm.graph.exe.ProcessInstance#15967 for a node that doesn't exist yet. Process as an add. | 2009-09-22 15:56:03,536 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/Token/org.jbpm.graph.exe.Token#15969 for a node that doesn't exist yet. Process as an add. | 2009-09-22 15:56:03,536 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/Token/org.jbpm.graph.exe.Token#15971 for a node that doesn't exist yet. Process as an add. | 2009-09-22 15:56:03,536 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/Token/org.jbpm.graph.exe.Token#15972 for a node that doesn't exist yet. Process as an add. | 2009-09-22 15:56:03,536 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/Token/org.jbpm.graph.exe.Token#15973 for a node that doesn't exist yet. Process as an add. | 2009-09-22 15:56:03,536 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Adding element /org/jbpm/graph/exe/Token/org.jbpm.graph.exe.Token#15974 for a node that doesn't exist yet. Process as an add. | The problem is that on node 2, the number of cache contents does not go up like it does on node 1. Cache contents on node 2 remain the same after the operation. If I execute the same operation on node 2, then the execution goes as slow as on node 1 before it had populated its cache. Node 2's cache contents go up then, and reach the same level as on node 1. So it looks like the caches of both nodes operate independently, regardless of what the logs say. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4256404#4256404 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4256404 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache Users] - JBoss 4.2.2 with TreeCache 1.4.1.SP5: nodes, attributes not
Hi!
I have a clustered TreeCache set up on the standard JBoss 4.2.2 GA release (for
caching jBPM-BPEL data).
It seems that the contents of the cache are properly replicated only during the
initial state transfer - when a node joins the cluster, the logs show:
2009-09-18 13:44:41,932 INFO [org.jboss.cache.TreeCache] received the state
(size=1024 bytes)
| 2009-09-18 13:44:41,936 INFO [org.jboss.cache.TreeCache] received the
state (size=1024 bytes)
| 2009-09-18 13:44:41,939 INFO [org.jboss.cache.TreeCache] received the
state (size=1024 bytes)
| 2009-09-18 13:44:41,942 INFO [org.jboss.cache.TreeCache] received the
state (size=1024 bytes)
| 2009-09-18 13:44:41,943 DEBUG
[org.jboss.hibernate.jbc.cacheprovider.OptimisticJBCCache]
activateCacheRegion(): Region /org/jbpm/graph/def/ProcessDefinition/a
| ctions is already active
| 2009-09-18 13:44:41,945 INFO [org.jboss.cache.TreeCache] received the
state (size=1024 bytes)
| 2009-09-18 13:44:41,946 DEBUG
[org.jboss.hibernate.jbc.cacheprovider.OptimisticJBCCache]
activateCacheRegion(): Region /org/jbpm/graph/def/ProcessDefinition/d
| efinitions is already active
While on the node that supplies the state transfer data, I can see in the logs:
2009-09-18 13:44:41,941 INFO
[org.jboss.cache.interceptors.OptimisticNodeInterceptor] read Method _getState;
id:19(/org/jbpm/file/def/FileDefinition/processF
| iles, 400, false, false) called - don't know how to handle, passing on!
| 2009-09-18 13:44:41,941 INFO
[org.jboss.cache.statetransfer.StateTransferGenerator_140] returning the state
for tree rooted in /org/jbpm/file/def/FileDefinit
| ion/processFiles(1024 bytes)
| 2009-09-18 13:44:41,944 INFO
[org.jboss.cache.interceptors.OptimisticNodeInterceptor] read Method _getState;
id:19(/org/jbpm/bpel/graph/scope/Scope/onEvents,
| 400, false, false) called - don't know how to handle, passing on!
| 2009-09-18 13:44:41,944 INFO
[org.jboss.cache.statetransfer.StateTransferGenerator_140] returning the state
for tree rooted in /org/jbpm/bpel/graph/scope/Sco
| pe/onEvents(1024 bytes)
| 2
During normal operation, however, it seems that cache contents aren't
replicated.
I'm looking at the attributes of the jboss.cache:service=MyTreeCache MBean.
When I execute a business process on node A, then I can see rapid growth of the
NumberOfAttributes and NumberOfNodes attribute values (until the cache gets
saturated).
But the expected synchronous growth on node B doesn't happen. When I do the
same on node B, the counts rise on that node, but node A remains uninfluenced.
So I suspect that cache replication does not work. Or maybe it should work that
way? Maybe I am looking at the wrong MBean attributes?
Here's the configuration of my TreeCache:
| ?xml version=1.0 encoding=UTF-8?
| server
| mbean code=org.jboss.cache.TreeCache
name=jboss.cache:service=MyTreeCache
| dependsjboss:service=Naming/depends
| dependsjboss:service=TransactionManager/depends
|
| !-- Configure the TransactionManager --
| attribute
name=TransactionManagerLookupClassorg.jboss.cache.JBossTransactionManagerLookup
| /attribute
|
| !--
| Node locking scheme :
| PESSIMISTIC (default)
| OPTIMISTIC
| --
| attribute name=NodeLockingSchemeOPTIMISTIC/attribute
|
| !--
| Node locking isolation level : SERIALIZABLE REPEATABLE_READ (default)
READ_COMMITTED READ_UNCOMMITTED NONE
| (ignored if NodeLockingScheme is OPTIMISTIC)
| --
| attribute name=IsolationLevelREPEATABLE_READ/attribute
|
| !--
| Valid modes are LOCAL REPL_ASYNC REPL_SYNC INVALIDATION_ASYNC
INVALIDATION_SYNC
| --
| attribute name=CacheModeREPL_ASYNC/attribute
|
| !-- Whether each interceptor should have an mbean
| registered to capture and display its statistics. --
| !-- javax.management.AttributeNotFoundException: Attribute
'UseInterceptorMbeans' is not writable --
| !--
| attribute name=UseInterceptorMbeanstrue/attribute
| --
|
| attribute name=UseRegionBasedMarshallingtrue/attribute
| attribute name=InactiveOnStartuptrue/attribute
|
| !-- Name of cluster. Needs to be the same for all clusters, in order
| to find each other --
| attribute
name=ClusterName${jboss.partition.name:DefaultPartition}-MyTreeCache
| /attribute
|
| attribute name=ClusterConfig
| config
| UDP mcast_addr=${jboss.partition.udpGroup:228.1.4.5}
mcast_port=${jboss.hapartition.mcast_port:48566}
| tos=8 ucast_recv_buf_size=2000
ucast_send_buf_size=64 mcast_recv_buf_size=2500
| mcast_send_buf_size=64 loopback=false
discard_incompatible_packets=true enable_bundling=false
| max_bundle_size=64000 max_bundle_timeout=30
use_incoming_packet_handler=true
| use_outgoing_packet_handler=false
[jboss-user] [JBoss Cache Users] - Re: JBoss 4.2.2 with TreeCache 1.4.1.SP5: nodes, attributes
BTW, anticipating th question: I can see that indeed the cache cluster gets formed, I can see the IP addresses of all the members in the Members attribute of the TreeCache MBean, the list of node IP addresses and their ports is identical on all cluster members. Only one of all the cluster nodes has a TreeCache MBean with Coordinator=true. The exact TreeCache version reported by the MBean is: JBossCache 'Cayenne' 1.4.1.SP5[ $Id: Version.java 4510 2007-09-26 18:45:19Z manik.surt...@jboss.com $] The only problem I see is that the number of nodes on the caches seems to be indepentent of each other, which suggests that they don't really replicate. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4256107#4256107 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4256107 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
