Somebody's broken the integration project release. There should be a jboss-integration.jar maven assembly. See build/build-distr.xml It was there in beta3 http://repository.jboss.com/jboss/integration/5.0.0.Beta3/component-info.xml but the structure of this release has been totally changed in beta4 http://repository.jboss.com/jboss/integration/5.0.0.Beta4/component-info.xml There's no assembly any more????? On Fri, 2007-10-19 at 16:23 +0300, Dimitris Andreadis wrote: > The testsuite runs of AS5 fail: > https://hudson.jboss.org/hudson/job/JBoss-AS-5.0.x-TestSuite-sun15-noip/95/ > > It cannot instantiate the transaction manager due to missing org/jboss/tm/JBossXATerminator. > > It's weird because the 'all' config boots manually. > > The missing class is in the jboss-integration.jar It will boot manually if you previously downloaded the integration beta3 release. The build-thirdparty.xml does not delete old jars so you will still have it in thirdparty. It won't build manually if you "rm -rf thirdparty" :-)

After fixing the JMS problem, I'm now seeing a hang in JBoss Cache: "main" prio=1 tid=0x80b31a18 nid=0x40a4 in Object.wait() [0x80453000..0x80455fb0] at java.lang.Object.wait(Native Method) - waiting on <0xb0ba95f0> (a java.lang.Object) at java.lang.Object.wait(Object.java:474) at org.jboss.cache.CacheImpl $MessageListenerAdaptor.waitForState(CacheImpl.java:3379) - locked <0xb0ba95f0> (a java.lang.Object) at org.jboss.cache.CacheImpl.fetchStateOnStartup(CacheImpl.java:1273) at org.jboss.cache.CacheImpl.internalStart(CacheImpl.java:767) at org.jboss.cache.CacheImpl.start(CacheImpl.java:708) at org.jboss.cache.jmx.CacheJmxWrapper.start(CacheJmxWrapper.java:614) Brian? :-) On Fri, 2007-10-19 at 16:37 +0200, Adrian wrote: > On Fri, 2007-10-19 at 16:17 +0200, Adrian wrote: >> I checked out the Beta4 tag and built the assembly. >> >> I've added it to the repository, so we're just waiting >> for the mirroring to catch up so we can test it. > The TM problem is fixed, I'm seeing a different problem > now relating to jgroups or jboss messaging? > (the default configuration boots fine). > > 16:33:06,342 ERROR [ExceptionUtil] org.jboss.messaging.core.jmx.MessagingPostOfficeService@9198a2 startService > java.lang.NullPointerException: the specifed protocol stack > configuration was null > at > org.jgroups.conf.ConfiguratorFactory.checkForNullConfiguration(ConfiguratorFactory.java:482) > at > org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:150) > at org.jgroups.JChannel.<init>(JChannel.java:195) > at > org.jboss.messaging.core.impl.jchannelfactory.XMLChannelFactory.createControlChannel(XMLChannelFactory.java:80) > at > org.jboss.messaging.core.impl.postoffice.GroupMember.start(GroupMember.java:124) >

I'm not seeing this. Can you provide any more details on how/when it occurs?

Brian Stansberry wrote: > Looking at it. > > Adrian wrote: >> After fixing the JMS problem, I'm now seeing a hang in JBoss Cache: >> >> "main" prio=1 tid=0x80b31a18 nid=0x40a4 in Object.wait() >> [0x80453000..0x80455fb0] >> at java.lang.Object.wait(Native Method) >> - waiting on <0xb0ba95f0> (a java.lang.Object) >> at java.lang.Object.wait(Object.java:474) >> at org.jboss.cache.CacheImpl >> $MessageListenerAdaptor.waitForState(CacheImpl.java:3379) >> - locked <0xb0ba95f0> (a java.lang.Object) >> at >> org.jboss.cache.CacheImpl.fetchStateOnStartup(CacheImpl.java:1273) >> at org.jboss.cache.CacheImpl.internalStart(CacheImpl.java:767) >> at org.jboss.cache.CacheImpl.start(CacheImpl.java:708) >> at >> org.jboss.cache.jmx.CacheJmxWrapper.start(CacheJmxWrapper.java:614) >> >> Brian? :-)

When I look at this code, it looks like it is doing an infinte wait, shouldn't this have a timeout? http://fisheye.jboss.org/browse/JBossCache/core/tags/2.0.0.GA/src/org/jbo...

On Tue, 2007-10-23 at 14:32 +0200, Adrian wrote: > On Fri, 2007-10-19 at 11:58 -0500, Brian Stansberry wrote: >> I'm not seeing this. Can you provide any more details on how/when it occurs? >> > I just boot the all configuration (jboss-head) > with the following command line: > ./run.sh -b localhost -c all > > It then hangs (there's no errors at DEBUG either in the log > - but there is lots of stuff that should really be TRACE :-) > > 14:28:25,944 INFO [UnifiedInvokerHA] Service name is > jboss:service=invoker,type=unifiedha > 14:28:28,214 INFO [STDOUT] > ------------------------------------------------------- > GMS: address is 127.0.0.1:32786 > ------------------------------------------------------- > 14:28:30,391 INFO [STDOUT] > ------------------------------------------------------- > GMS: address is 127.0.0.1:32787 > ------------------------------------------------------- > 14:28:32,490 INFO [QueueService] Queue[/queue/DLQ] started, > fullSize=200000, pageSize=2000, downCacheSize=2000 > 14:28:33,146 INFO [ConnectionFactory] Connector > bisocket://localhost:4457 has leasing enabled, lease period 10000 > milliseconds > 14:28:33,147 INFO [ConnectionFactory] > org.jboss.jms.server.connectionfactory.ConnectionFactory@6985a3 started > 14:28:33,148 INFO [QueueService] Queue[/queue/ExpiryQueue] started, > fullSize=200000, pageSize=2000, downCacheSize=2000 > 14:28:33,725 WARN [SecurityMetadataStore] WARNING! POTENTIAL SECURITY > RISK. It has been detected that the MessageSucker component which sucks > messages from one node to another has not had its password changed from > the installation default. Please see the userguide for instructions on > how to do this. > 14:28:34,331 INFO [ConnectionFactory] Connector > bisocket://localhost:4457 has leasing enabled, lease period 10000 > milliseconds > 14:28:34,331 INFO [ConnectionFactory] > org.jboss.jms.server.connectionfactory.ConnectionFactory@15b5376 started > 14:28:34,334 INFO [ConnectionFactory] Connector > bisocket://localhost:4457 has leasing enabled, lease period 10000 > milliseconds > 14:28:34,334 INFO [ConnectionFactory] > org.jboss.jms.server.connectionfactory.ConnectionFactory@7b954b started > 14:28:34,902 INFO [DefaultPartition-ClusteredSSOCache] viewAccepted(): > [127.0.0.1:32787|0] [127.0.0.1:32787] > 14:28:34,903 INFO [DefaultPartition-ClusteredSSOCache] CacheImpl local > address is 127.0.0.1:32787 > > STOPS HERE the thread dump is as below! > >> Brian Stansberry wrote: >>> Looking at it. >>> >>> Adrian wrote: >>>> After fixing the JMS problem, I'm now seeing a hang in JBoss Cache: >>>> >>>> "main" prio=1 tid=0x80b31a18 nid=0x40a4 in Object.wait() >>>> [0x80453000..0x80455fb0] >>>> at java.lang.Object.wait(Native Method) >>>> - waiting on <0xb0ba95f0> (a java.lang.Object) >>>> at java.lang.Object.wait(Object.java:474) >>>> at org.jboss.cache.CacheImpl >>>> $MessageListenerAdaptor.waitForState(CacheImpl.java:3379) >>>> - locked <0xb0ba95f0> (a java.lang.Object) >>>> at >>>> org.jboss.cache.CacheImpl.fetchStateOnStartup(CacheImpl.java:1273) >>>> at org.jboss.cache.CacheImpl.internalStart(CacheImpl.java:767) >>>> at org.jboss.cache.CacheImpl.start(CacheImpl.java:708) >>>> at >>>> org.jboss.cache.jmx.CacheJmxWrapper.start(CacheJmxWrapper.java:614) >>>> >>>> Brian? :-)

On Tue, 2007-10-23 at 09:58 -0500, Brian Stansberry wrote: > Adrian wrote: >> When I look at this code, it looks like it is doing an infinte wait, >> shouldn't this have a timeout? >> >> http://fisheye.jboss.org/browse/JBossCache/core/tags/2.0.0.GA/src/org/jbo... >> > Arguably yes, although only as a second line of defense against a bug. > Which there appears to be here. You only get to the wait call if > channel.getState() returns true (line 1270 in the above linked rev.) > The getState call has a timeout. In your case it should *not* have > returned true, as your node is the only cluster member. > > Vladimir/Manik, does anything here ring a bell? E.g. was there any > change in the Channel.getState() behavior in JG 2.5.0? Adrian's seeing > this in AS trunk, which is using JBC 2.0.0.GA and JG 2.5.0.GA. > Make sure you do an rm -rf thirdparty or use a clean checkout so you can be sure you have all the latest jars.

> Adrian, has some kind of parallelization of deployment been introduced? No. But each service is free to do some startup asynch by forking a thread. > Your logging seems to show JBoss Messaging deployment proceeding in > parallel with deployment of cluster-beans.xml. When I run "./run.sh -b > localhost -c all" I don't see this problem (and the JBM logging occurs > after the cluster-beans.xml stuff.) So you think this could be a race? I don't see anything in the DEBUG messages (or the thread dump) that suggests both are active at the same time. Here's the DEBUG from the last JBoss Messaging logging:

2007-10-23 14:28:34,335 DEBUG [org.jboss.jms.server.connectionfactory.ConnectionFactory] Started jboss.messaging.connectionfactory:service=ConnectionFactory 2007-10-23 14:28:34,336 DEBUG [org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback] Registered MBean jboss.jgroups:service=MultiplexerChannelFactory 2007-10-23 14:28:34,337 DEBUG [org.jboss.ha.framework.server.JChannelFactory] Ignoring create call; current state is Started 2007-10-23 14:28:34,337 DEBUG [org.jboss.ha.framework.server.JChannelFactory] Ignoring start call; current state is Started 2007-10-23 14:28:34,362 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] Registered in JMX under jboss.cache:service=EJB3SFSBClusteredCache 2007-10-23 14:28:34,362 DEBUG [org.jboss.system.ServiceController] starting service jboss.cache:service=EJB3SFSBClusteredCache 2007-10-23 14:28:34,362 DEBUG [org.jboss.system.ServiceController] Registering service jboss.cache:service=EJB3SFSBClusteredCache 2007-10-23 14:28:34,373 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] Registered in JMX under jboss.cache:partitionName=DefaultPartition,service=HAPartitionCache 2007-10-23 14:28:34,374 DEBUG [org.jboss.system.ServiceController] starting service jboss.cache:service=HAPartitionCache,partitionName=DefaultPartition 2007-10-23 14:28:34,374 DEBUG [org.jboss.system.ServiceController] Registering service jboss.cache:service=HAPartitionCache,partitionName=DefaultPartition 2007-10-23 14:28:34,384 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] Registered in JMX under jboss.cache:service=ClusteredSSOCache 2007-10-23 14:28:34,384 DEBUG [org.jboss.system.ServiceController] starting service jboss.cache:service=ClusteredSSOCache 2007-10-23 14:28:34,384 DEBUG [org.jboss.system.ServiceController] Registering service jboss.cache:service=ClusteredSSOCache 2007-10-23 14:28:34,390 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] Constructing Cache 2007-10-23 14:28:34,797 DEBUG [org.jboss.cache.factories.InterceptorChainFactory] interceptor chain is: class org.jboss.cache.interceptors.CallInterceptor class org.jboss.cache.interceptors.UnlockInterceptor class org.jboss.cache.interceptors.PessimisticLockInterceptor class org.jboss.cache.interceptors.ReplicationInterceptor class org.jboss.cache.interceptors.NotificationInterceptor class org.jboss.cache.interceptors.TxInterceptor class org.jboss.cache.interceptors.CacheMgmtInterceptor class org.jboss.cache.interceptors.InvocationContextInterceptor 2007-10-23 14:28:34,806 DEBUG [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Not using an EvictionPolicy 2007-10-23 14:28:34,815 DEBUG [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] cache mode is REPL_ASYNC 2007-10-23 14:28:34,815 DEBUG [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Created Multiplexer Channel for cache cluster DefaultPartition-ClusteredSS OCache using stack udp 2007-10-23 14:28:34,844 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Initialised with version 2.0.0 and versionInt 20 2007-10-23 14:28:34,844 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Using default marshaller class org.jboss.cache.marshall.CacheMarshaller200 2007-10-23 14:28:34,844 DEBUG [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Using marshaller org.jboss.cache.marshall.VersionAwareMarshaller 2007-10-23 14:28:34,845 DEBUG [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Block received at 127.0.0.1:32787 2007-10-23 14:28:34,899 DEBUG [org.jboss.cache.interceptors.InvocationContextInterceptor] Invoked on cache instance [127.0.0.1:32787] and InvocationContext [Invocation Context{methodCall=MethodName: _block; MethodIdInteger: 43; Args: ()transaction=null, globalTransaction=null, optionOverrides=Option{failSilently=false, cacheModeLocal =false, dataVersion=null, suppressLocking=false, forceDataGravitation=false, skipDataGravitation=false}, originLocal=true, txHasMods=false}] 2007-10-23 14:28:34,899 DEBUG [org.jboss.cache.interceptors.InvocationContextInterceptor] Setting up transactional context. 2007-10-23 14:28:34,899 DEBUG [org.jboss.cache.interceptors.InvocationContextInterceptor] Setting tx as null and gtx as null 2007-10-23 14:28:34,900 DEBUG [org.jboss.cache.interceptors.ReplicationInterceptor] isLocalCommitOrRollback? false; gtx = null 2007-10-23 14:28:34,900 DEBUG [org.jboss.cache.interceptors.PessimisticLockInterceptor] PessimisticLockInterceptor invoked for method MethodName: _block; MethodIdInteg er: 43; Args: () 2007-10-23 14:28:34,900 DEBUG [org.jboss.cache.interceptors.PessimisticLockInterceptor] bypassed locking as method _block() doesn't require locking 2007-10-23 14:28:34,900 DEBUG [org.jboss.cache.interceptors.CallInterceptor] Passing up method MethodName: _block; MethodIdInteger: 43; Args: () so it gets invoked on cache. 2007-10-23 14:28:34,900 DEBUG [org.jboss.cache.interceptors.UnlockInterceptor] Attempting to release locks on current thread. Lock table is {} 2007-10-23 14:28:34,900 DEBUG [org.jboss.cache.interceptors.ReplicationInterceptor] Non-tx and non crud meth 2007-10-23 14:28:34,900 DEBUG [org.jboss.cache.interceptors.InvocationContextInterceptor] Resetting invocation-scope options 2007-10-23 14:28:34,900 DEBUG [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Block processed at 127.0.0.1:32787 2007-10-23 14:28:34,902 INFO [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] viewAccepted(): [127.0.0.1:32787|0] [127.0.0.1:32787] 2007-10-23 14:28:34,902 DEBUG [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] UnBlock received at 127.0.0.1:32787 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.interceptors.InvocationContextInterceptor] Invoked on cache instance [127.0.0.1:32787] and InvocationContext [Invocation Context{methodCall=MethodName: _unblock; MethodIdInteger: 44; Args: ()transaction=null, globalTransaction=null, optionOverrides=Option{failSilently=false, cacheModeLoc al=false, dataVersion=null, suppressLocking=false, forceDataGravitation=false, skipDataGravitation=false}, originLocal=true, txHasMods=false}] 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.interceptors.InvocationContextInterceptor] Setting up transactional context. 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.interceptors.InvocationContextInterceptor] Setting tx as null and gtx as null 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.interceptors.ReplicationInterceptor] isLocalCommitOrRollback? false; gtx = null 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.interceptors.PessimisticLockInterceptor] PessimisticLockInterceptor invoked for method MethodName: _unblock; MethodIdInt eger: 44; Args: () 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.interceptors.PessimisticLockInterceptor] bypassed locking as method _unblock() doesn't require locking 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.interceptors.CallInterceptor] Passing up method MethodName: _unblock; MethodIdInteger: 44; Args: () so it gets invoked o n cache. 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.interceptors.UnlockInterceptor] Attempting to release locks on current thread. Lock table is {} 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.interceptors.ReplicationInterceptor] Non-tx and non crud meth 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.interceptors.InvocationContextInterceptor] Resetting invocation-scope options 2007-10-23 14:28:34,903 DEBUG [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] UnBlock processed at 127.0.0.1:32787 2007-10-23 14:28:34,903 INFO [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] CacheImpl local address is 127.0.0.1:32787 Got bored waiting here. ;-) 2007-10-23 14:32:30,094 INFO [org.jboss.bootstrap.microcontainer.ServerImpl] JBoss SHUTDOWN There's no JBoss Cache logging before this, only some generic clustering logging (I've included where jms is using clustering but otherwise stripped its logging): 2007-10-23 14:28:27,360 DEBUG [org.jboss.system.ServiceController] starting service jboss.jgroups:service=MultiplexerChannelFactory 2007-10-23 14:28:27,360 DEBUG [org.jboss.system.ServiceController] Registering service jboss.jgroups:service=MultiplexerChannelFactory 2007-10-23 14:28:27,364 DEBUG [org.jboss.ha.framework.server.JChannelFactory] Ignoring create call; current state is Stopped ... 2007-10-23 14:28:27,367 DEBUG [org.jboss.ha.framework.server.JChannelFactory] Starting JChannelFactory 2007-10-23 14:28:27,367 DEBUG [org.jboss.ha.framework.server.JChannelFactory] Started JChannelFactory 2007-10-23 14:28:27,368 DEBUG [org.jboss.messaging.core.jmx.MessagingPostOfficeService] Starting jboss.messaging:service=PostOffice 2007-10-23 14:28:27,378 DEBUG [org.jboss.messaging.core.jmx.MessagingPostOfficeService] org.jboss.messaging.core.jmx.MessagingPostOfficeService@14b7042 uses Multiplexe rJChannelFactory 2007-10-23 14:28:28,110 DEBUG [org.jboss.ha.framework.server.JChannelFactory] Passing unique node id 127.0.0.1:1099 to the channel as additional data 2007-10-23 14:28:28,121 DEBUG [org.jboss.ha.framework.server.JChannelFactory] Passing unique node id 127.0.0.1:1099 to the channel as additional data 2007-10-23 14:28:28,214 INFO [STDOUT] ------------------------------------------------------- GMS: address is 127.0.0.1:32786 ------------------------------------------------------- 2007-10-23 14:28:30,306 DEBUG [org.jboss.messaging.core.impl.postoffice.GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember $ControlMembershipListener@334 cb9 got new view [127.0.0.1:32786|0] [127.0.0.1:32786], old view is null 2007-10-23 14:28:30,386 DEBUG [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] org.jboss.messaging.core.impl.postoffice.MessagingPostOffice@1c86116: 127. 0.0.1:32786 joined 2007-10-23 14:28:30,386 DEBUG [org.jboss.messaging.core.impl.postoffice.GroupMember] First view arrived 2007-10-23 14:28:30,387 DEBUG [org.jboss.messaging.core.impl.postoffice.GroupMember] We are the first member of the group so no need to wait for state 2007-10-23 14:28:30,391 INFO [STDOUT] ------------------------------------------------------- GMS: address is 127.0.0.1:32787 ------------------------------------------------------- 2007-10-23 14:28:32,412 DEBUG [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] Updated failover map: 0->0 2007-10-23 14:28:32,427 DEBUG [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] org.jboss.messaging.core.impl.postoffice.MessagingPostOffice@1c86116 puts replicant locally: JVMID->6-fnu8e48f-1-yvy7e48f-0gpx6x-d24o4c5 ... 2007-10-23 14:28:32,872 DEBUG [org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint] updateClusteredClients being called!!! clientFactoriesToUpdate.size = 0 ,,, 2007-10-23 14:28:34,335 DEBUG [org.jboss.jms.server.connectionfactory.ConnectionFactory] Started jboss.messaging.connectionfactory:service=ConnectionFactory 2007-10-23 14:28:34,336 DEBUG [org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback] Registered MBean jboss.jgroups:service=MultiplexerChannelFactory 2007-10-23 14:28:34,337 DEBUG [org.jboss.ha.framework.server.JChannelFactory] Ignoring create call; current state is Started 2007-10-23 14:28:34,337 DEBUG [org.jboss.ha.framework.server.JChannelFactory] Ignoring start call; current state is Started

The cause of this is http://jira.jboss.com/jira/browse/JBMESSAGING-1120. Vladimir's written a unit test that shows the combination of the way JBM uses a shared channel and the other AS services use it leads to the behavior we're seeing. The JBM guys fixing JBMESSAGING-1120 will make the problem go away. I've asked Vladimir look into why the JBM usage caused Channel.getState() to incorrectly return true, which is what led to the hang. Brian Stansberry wrote: > Adrian wrote: >> On Tue, 2007-10-23 at 09:58 -0500, Brian Stansberry wrote: >>> Adrian wrote: >>>> When I look at this code, it looks like it is doing an infinte wait, >>>> shouldn't this have a timeout? >>>> >>>> http://fisheye.jboss.org/browse/JBossCache/core/tags/2.0.0.GA/src/org/jbo... >>>> >>>> >>> Arguably yes, although only as a second line of defense against a >>> bug. Which there appears to be here. You only get to the wait call >>> if channel.getState() returns true (line 1270 in the above linked >>> rev.) The getState call has a timeout. In your case it should *not* >>> have returned true, as your node is the only cluster member. >>> >>> Vladimir/Manik, does anything here ring a bell? E.g. was there any >>> change in the Channel.getState() behavior in JG 2.5.0? Adrian's >>> seeing this in AS trunk, which is using JBC 2.0.0.GA and JG 2.5.0.GA. >>> >> >> Make sure you do an rm -rf thirdparty or use a clean checkout >> so you can be sure you have all the latest jars. >> > > Yeah, I did. > >>> Adrian, has some kind of parallelization of deployment been introduced? >> >> No. But each service is free to do some startup asynch by forking >> a thread. >> >>> Your logging seems to show JBoss Messaging deployment proceeding in >>> parallel with deployment of cluster-beans.xml. When I run "./run.sh >>> -b localhost -c all" I don't see this problem (and the JBM logging >>> occurs after the cluster-beans.xml stuff.) >> >> So you think this could be a race? I don't see anything in the >> DEBUG messages (or the thread dump) that suggests both are >> active at the same time. >> >> Here's the DEBUG from the last JBoss Messaging logging: >> > > Thanks for this. I'd misread your earlier log; saw two sets of ASCII > art showing channels starting, and thought one was JBM deployment, one > from JBC. Actually, they were both from JBM, which creates 2 channels. > > The JBC that's hanging actually shares the 2nd channel with JBM. This > is likely where the problem is; some defect in the state transfer > handling with shared channels. When I launch AS, the JBC deployment is > happening before JBM; for whatever reason for you it's JBM then JBC. > I'll add a depends or something to force JBM to go first on my setup > and I bet I'll see the same thing you do. > >> 2007-10-23 14:28:34,335 DEBUG >> [org.jboss.jms.server.connectionfactory.ConnectionFactory] Started >> jboss.messaging.connectionfactory:service=ConnectionFactory >> 2007-10-23 14:28:34,336 DEBUG >> [org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback] >> Registered MBean jboss.jgroups:service=MultiplexerChannelFactory >> 2007-10-23 14:28:34,337 DEBUG >> [org.jboss.ha.framework.server.JChannelFactory] Ignoring create call; >> current state is Started >> 2007-10-23 14:28:34,337 DEBUG >> [org.jboss.ha.framework.server.JChannelFactory] Ignoring start call; >> current state is Started >> 2007-10-23 14:28:34,362 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] >> Registered in JMX under jboss.cache:service=EJB3SFSBClusteredCache >> 2007-10-23 14:28:34,362 DEBUG [org.jboss.system.ServiceController] >> starting service jboss.cache:service=EJB3SFSBClusteredCache >> 2007-10-23 14:28:34,362 DEBUG [org.jboss.system.ServiceController] >> Registering service jboss.cache:service=EJB3SFSBClusteredCache >> 2007-10-23 14:28:34,373 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] >> Registered in JMX under >> jboss.cache:partitionName=DefaultPartition,service=HAPartitionCache >> 2007-10-23 14:28:34,374 DEBUG [org.jboss.system.ServiceController] >> starting service >> jboss.cache:service=HAPartitionCache,partitionName=DefaultPartition >> 2007-10-23 14:28:34,374 DEBUG [org.jboss.system.ServiceController] >> Registering service >> jboss.cache:service=HAPartitionCache,partitionName=DefaultPartition >> 2007-10-23 14:28:34,384 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] >> Registered in JMX under jboss.cache:service=ClusteredSSOCache >> 2007-10-23 14:28:34,384 DEBUG [org.jboss.system.ServiceController] >> starting service jboss.cache:service=ClusteredSSOCache >> 2007-10-23 14:28:34,384 DEBUG [org.jboss.system.ServiceController] >> Registering service jboss.cache:service=ClusteredSSOCache >> 2007-10-23 14:28:34,390 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] >> Constructing Cache >> 2007-10-23 14:28:34,797 DEBUG >> [org.jboss.cache.factories.InterceptorChainFactory] interceptor chain >> is: >> class org.jboss.cache.interceptors.CallInterceptor >> class org.jboss.cache.interceptors.UnlockInterceptor >> class org.jboss.cache.interceptors.PessimisticLockInterceptor >> class org.jboss.cache.interceptors.ReplicationInterceptor >> class org.jboss.cache.interceptors.NotificationInterceptor >> class org.jboss.cache.interceptors.TxInterceptor >> class org.jboss.cache.interceptors.CacheMgmtInterceptor >> class org.jboss.cache.interceptors.InvocationContextInterceptor >> 2007-10-23 14:28:34,806 DEBUG >> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Not using >> an EvictionPolicy >> 2007-10-23 14:28:34,815 DEBUG >> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] cache >> mode is REPL_ASYNC >> 2007-10-23 14:28:34,815 DEBUG >> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Created >> Multiplexer Channel for cache cluster DefaultPartition-ClusteredSS >> OCache using stack udp >> 2007-10-23 14:28:34,844 DEBUG >> [org.jboss.cache.marshall.VersionAwareMarshaller] Initialised with >> version 2.0.0 and versionInt 20 >> 2007-10-23 14:28:34,844 DEBUG >> [org.jboss.cache.marshall.VersionAwareMarshaller] Using default >> marshaller class org.jboss.cache.marshall.CacheMarshaller200 >> 2007-10-23 14:28:34,844 DEBUG >> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Using >> marshaller org.jboss.cache.marshall.VersionAwareMarshaller >> 2007-10-23 14:28:34,845 DEBUG >> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Block >> received at 127.0.0.1:32787 >> 2007-10-23 14:28:34,899 DEBUG >> [org.jboss.cache.interceptors.InvocationContextInterceptor] Invoked on >> cache instance [127.0.0.1:32787] and InvocationContext [Invocation >> Context{methodCall=MethodName: _block; MethodIdInteger: 43; Args: >> ()transaction=null, globalTransaction=null, >> optionOverrides=Option{failSilently=false, cacheModeLocal >> =false, dataVersion=null, suppressLocking=false, >> forceDataGravitation=false, skipDataGravitation=false}, >> originLocal=true, txHasMods=false}] >> 2007-10-23 14:28:34,899 DEBUG >> [org.jboss.cache.interceptors.InvocationContextInterceptor] Setting up >> transactional context. >> 2007-10-23 14:28:34,899 DEBUG >> [org.jboss.cache.interceptors.InvocationContextInterceptor] Setting tx >> as null and gtx as null >> 2007-10-23 14:28:34,900 DEBUG >> [org.jboss.cache.interceptors.ReplicationInterceptor] >> isLocalCommitOrRollback? false; gtx = null >> 2007-10-23 14:28:34,900 DEBUG >> [org.jboss.cache.interceptors.PessimisticLockInterceptor] >> PessimisticLockInterceptor invoked for method MethodName: _block; >> MethodIdInteg >> er: 43; Args: () >> 2007-10-23 14:28:34,900 DEBUG >> [org.jboss.cache.interceptors.PessimisticLockInterceptor] bypassed >> locking as method _block() doesn't require locking >> 2007-10-23 14:28:34,900 DEBUG >> [org.jboss.cache.interceptors.CallInterceptor] Passing up method >> MethodName: _block; MethodIdInteger: 43; Args: () so it gets invoked >> on cache. >> 2007-10-23 14:28:34,900 DEBUG >> [org.jboss.cache.interceptors.UnlockInterceptor] Attempting to release >> locks on current thread. Lock table is {} >> 2007-10-23 14:28:34,900 DEBUG >> [org.jboss.cache.interceptors.ReplicationInterceptor] Non-tx and non >> crud meth >> 2007-10-23 14:28:34,900 DEBUG >> [org.jboss.cache.interceptors.InvocationContextInterceptor] Resetting >> invocation-scope options >> 2007-10-23 14:28:34,900 DEBUG >> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Block >> processed at 127.0.0.1:32787 >> 2007-10-23 14:28:34,902 INFO >> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] >> viewAccepted(): [127.0.0.1:32787|0] [127.0.0.1:32787] >> 2007-10-23 14:28:34,902 DEBUG >> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] UnBlock >> received at 127.0.0.1:32787 >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.interceptors.InvocationContextInterceptor] Invoked on >> cache instance [127.0.0.1:32787] and InvocationContext [Invocation >> Context{methodCall=MethodName: _unblock; MethodIdInteger: 44; Args: >> ()transaction=null, globalTransaction=null, >> optionOverrides=Option{failSilently=false, cacheModeLoc >> al=false, dataVersion=null, suppressLocking=false, >> forceDataGravitation=false, skipDataGravitation=false}, >> originLocal=true, txHasMods=false}] >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.interceptors.InvocationContextInterceptor] Setting up >> transactional context. >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.interceptors.InvocationContextInterceptor] Setting tx >> as null and gtx as null >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.interceptors.ReplicationInterceptor] >> isLocalCommitOrRollback? false; gtx = null >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.interceptors.PessimisticLockInterceptor] >> PessimisticLockInterceptor invoked for method MethodName: _unblock; >> MethodIdInt >> eger: 44; Args: () >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.interceptors.PessimisticLockInterceptor] bypassed >> locking as method _unblock() doesn't require locking >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.interceptors.CallInterceptor] Passing up method >> MethodName: _unblock; MethodIdInteger: 44; Args: () so it gets invoked o >> n cache. >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.interceptors.UnlockInterceptor] Attempting to release >> locks on current thread. Lock table is {} >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.interceptors.ReplicationInterceptor] Non-tx and non >> crud meth >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.interceptors.InvocationContextInterceptor] Resetting >> invocation-scope options >> 2007-10-23 14:28:34,903 DEBUG >> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] UnBlock >> processed at 127.0.0.1:32787 >> 2007-10-23 14:28:34,903 INFO >> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] CacheImpl >> local address is 127.0.0.1:32787 >> >> Got bored waiting here. ;-) >> >> 2007-10-23 14:32:30,094 INFO >> [org.jboss.bootstrap.microcontainer.ServerImpl] JBoss SHUTDOWN >> >> >> There's no JBoss Cache logging before this, only some generic >> clustering logging (I've included where jms is using clustering >> but otherwise stripped its logging): >> >> >> 2007-10-23 14:28:27,360 DEBUG [org.jboss.system.ServiceController] >> starting service jboss.jgroups:service=MultiplexerChannelFactory >> 2007-10-23 14:28:27,360 DEBUG [org.jboss.system.ServiceController] >> Registering service jboss.jgroups:service=MultiplexerChannelFactory >> 2007-10-23 14:28:27,364 DEBUG >> [org.jboss.ha.framework.server.JChannelFactory] Ignoring create call; >> current state is Stopped >> >> ... >> >> 2007-10-23 14:28:27,367 DEBUG >> [org.jboss.ha.framework.server.JChannelFactory] Starting JChannelFactory >> 2007-10-23 14:28:27,367 DEBUG >> [org.jboss.ha.framework.server.JChannelFactory] Started JChannelFactory >> 2007-10-23 14:28:27,368 DEBUG >> [org.jboss.messaging.core.jmx.MessagingPostOfficeService] Starting >> jboss.messaging:service=PostOffice >> 2007-10-23 14:28:27,378 DEBUG >> [org.jboss.messaging.core.jmx.MessagingPostOfficeService] >> org.jboss.messaging.core.jmx.MessagingPostOfficeService@14b7042 uses >> Multiplexe >> rJChannelFactory >> >> 2007-10-23 14:28:28,110 DEBUG >> [org.jboss.ha.framework.server.JChannelFactory] Passing unique node id >> 127.0.0.1:1099 to the channel as additional data >> 2007-10-23 14:28:28,121 DEBUG >> [org.jboss.ha.framework.server.JChannelFactory] Passing unique node id >> 127.0.0.1:1099 to the channel as additional data >> 2007-10-23 14:28:28,214 INFO [STDOUT] >> ------------------------------------------------------- >> GMS: address is 127.0.0.1:32786 >> ------------------------------------------------------- >> 2007-10-23 14:28:30,306 DEBUG >> [org.jboss.messaging.core.impl.postoffice.GroupMember] >> org.jboss.messaging.core.impl.postoffice.GroupMember >> $ControlMembershipListener@334 >> cb9 got new view [127.0.0.1:32786|0] [127.0.0.1:32786], old view is null >> 2007-10-23 14:28:30,386 DEBUG >> [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] >> org.jboss.messaging.core.impl.postoffice.MessagingPostOffice@1c86116: >> 127. >> 0.0.1:32786 joined >> 2007-10-23 14:28:30,386 DEBUG >> [org.jboss.messaging.core.impl.postoffice.GroupMember] First view >> arrived >> 2007-10-23 14:28:30,387 DEBUG >> [org.jboss.messaging.core.impl.postoffice.GroupMember] We are the first >> member of the group so no need to wait for state >> 2007-10-23 14:28:30,391 INFO [STDOUT] >> ------------------------------------------------------- >> GMS: address is 127.0.0.1:32787 >> ------------------------------------------------------- >> 2007-10-23 14:28:32,412 DEBUG >> [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] Updated >> failover map: >> >> 0->0 >> >> 2007-10-23 14:28:32,427 DEBUG >> [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] >> org.jboss.messaging.core.impl.postoffice.MessagingPostOffice@1c86116 >> puts replicant locally: JVMID->6-fnu8e48f-1-yvy7e48f-0gpx6x-d24o4c5 >> >> ... >> >> 2007-10-23 14:28:32,872 DEBUG >> [org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint] >> updateClusteredClients being called!!! clientFactoriesToUpdate.size = 0 >> >> ,,, >> >> 2007-10-23 14:28:34,335 DEBUG >> [org.jboss.jms.server.connectionfactory.ConnectionFactory] Started >> jboss.messaging.connectionfactory:service=ConnectionFactory >> 2007-10-23 14:28:34,336 DEBUG >> [org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback] >> Registered MBean jboss.jgroups:service=MultiplexerChannelFactory >> 2007-10-23 14:28:34,337 DEBUG >> [org.jboss.ha.framework.server.JChannelFactory] Ignoring create call; >> current state is Started >> 2007-10-23 14:28:34,337 DEBUG >> [org.jboss.ha.framework.server.JChannelFactory] Ignoring start call; >> current state is Started >> >

Are you sure getState() isn't being called? I need to check, but JBM should always be calling getState() after joining a channel. (Also.. the erroneous code comes from here http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118300 where Brian explained to us how to use a mux channel, I think it was just copy and pasted ;) ) Brian Stansberry wrote: > I've added a workaround to the AS[1] that should allow it to start > properly until JBMESSAGING-1120 is fixed. > > [1] http://jira.jboss.com/jira/browse/JBAS-4909 > > Brian Stansberry wrote: >> The cause of this is >> http://jira.jboss.com/jira/browse/JBMESSAGING-1120. Vladimir's >> written a unit test that shows the combination of the way JBM uses a >> shared channel and the other AS services use it leads to the >> behavior we're seeing. >> >> The JBM guys fixing JBMESSAGING-1120 will make the problem go away. >> I've asked Vladimir look into why the JBM usage caused >> Channel.getState() to incorrectly return true, which is what led to >> the hang. >> >> Brian Stansberry wrote: >>> Adrian wrote: >>>> On Tue, 2007-10-23 at 09:58 -0500, Brian Stansberry wrote: >>>>> Adrian wrote: >>>>>> When I look at this code, it looks like it is doing an infinte >>>>>> wait, >>>>>> shouldn't this have a timeout? >>>>>> >>>>>> http://fisheye.jboss.org/browse/JBossCache/core/tags/2.0.0.GA/src/org/jbo... >>>>>> >>>>>> >>>>> Arguably yes, although only as a second line of defense against a >>>>> bug. Which there appears to be here. You only get to the wait >>>>> call if channel.getState() returns true (line 1270 in the above >>>>> linked rev.) The getState call has a timeout. In your case it >>>>> should *not* have returned true, as your node is the only cluster >>>>> member. >>>>> >>>>> Vladimir/Manik, does anything here ring a bell? E.g. was there >>>>> any change in the Channel.getState() behavior in JG 2.5.0? >>>>> Adrian's seeing this in AS trunk, which is using JBC 2.0.0.GA and >>>>> JG 2.5.0.GA. >>>>> >>>> >>>> Make sure you do an rm -rf thirdparty or use a clean checkout >>>> so you can be sure you have all the latest jars. >>>> >>> >>> Yeah, I did. >>> >>>>> Adrian, has some kind of parallelization of deployment been >>>>> introduced? >>>> >>>> No. But each service is free to do some startup asynch by forking >>>> a thread. >>>> >>>>> Your logging seems to show JBoss Messaging deployment proceeding >>>>> in parallel with deployment of cluster-beans.xml. When I run >>>>> "./run.sh -b localhost -c all" I don't see this problem (and the >>>>> JBM logging occurs after the cluster-beans.xml stuff.) >>>> >>>> So you think this could be a race? I don't see anything in the >>>> DEBUG messages (or the thread dump) that suggests both are >>>> active at the same time. >>>> >>>> Here's the DEBUG from the last JBoss Messaging logging: >>>> >>> >>> Thanks for this. I'd misread your earlier log; saw two sets of >>> ASCII art showing channels starting, and thought one was JBM >>> deployment, one from JBC. Actually, they were both from JBM, which >>> creates 2 channels. >>> >>> The JBC that's hanging actually shares the 2nd channel with JBM. >>> This is likely where the problem is; some defect in the state >>> transfer handling with shared channels. When I launch AS, the JBC >>> deployment is happening before JBM; for whatever reason for you >>> it's JBM then JBC. I'll add a depends or something to force JBM to >>> go first on my setup and I bet I'll see the same thing you do. >>> >>>> 2007-10-23 14:28:34,335 DEBUG >>>> [org.jboss.jms.server.connectionfactory.ConnectionFactory] Started >>>> jboss.messaging.connectionfactory:service=ConnectionFactory >>>> 2007-10-23 14:28:34,336 DEBUG >>>> [org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback] >>>> >>>> Registered MBean jboss.jgroups:service=MultiplexerChannelFactory >>>> 2007-10-23 14:28:34,337 DEBUG >>>> [org.jboss.ha.framework.server.JChannelFactory] Ignoring create call; >>>> current state is Started >>>> 2007-10-23 14:28:34,337 DEBUG >>>> [org.jboss.ha.framework.server.JChannelFactory] Ignoring start call; >>>> current state is Started >>>> 2007-10-23 14:28:34,362 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] >>>> Registered in JMX under jboss.cache:service=EJB3SFSBClusteredCache >>>> 2007-10-23 14:28:34,362 DEBUG [org.jboss.system.ServiceController] >>>> starting service jboss.cache:service=EJB3SFSBClusteredCache >>>> 2007-10-23 14:28:34,362 DEBUG [org.jboss.system.ServiceController] >>>> Registering service jboss.cache:service=EJB3SFSBClusteredCache >>>> 2007-10-23 14:28:34,373 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] >>>> Registered in JMX under >>>> jboss.cache:partitionName=DefaultPartition,service=HAPartitionCache >>>> 2007-10-23 14:28:34,374 DEBUG [org.jboss.system.ServiceController] >>>> starting service >>>> jboss.cache:service=HAPartitionCache,partitionName=DefaultPartition >>>> 2007-10-23 14:28:34,374 DEBUG [org.jboss.system.ServiceController] >>>> Registering service >>>> jboss.cache:service=HAPartitionCache,partitionName=DefaultPartition >>>> 2007-10-23 14:28:34,384 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] >>>> Registered in JMX under jboss.cache:service=ClusteredSSOCache >>>> 2007-10-23 14:28:34,384 DEBUG [org.jboss.system.ServiceController] >>>> starting service jboss.cache:service=ClusteredSSOCache >>>> 2007-10-23 14:28:34,384 DEBUG [org.jboss.system.ServiceController] >>>> Registering service jboss.cache:service=ClusteredSSOCache >>>> 2007-10-23 14:28:34,390 DEBUG [org.jboss.cache.jmx.CacheJmxWrapper] >>>> Constructing Cache >>>> 2007-10-23 14:28:34,797 DEBUG >>>> [org.jboss.cache.factories.InterceptorChainFactory] interceptor chain >>>> is: >>>> class org.jboss.cache.interceptors.CallInterceptor >>>> class org.jboss.cache.interceptors.UnlockInterceptor >>>> class org.jboss.cache.interceptors.PessimisticLockInterceptor >>>> class org.jboss.cache.interceptors.ReplicationInterceptor >>>> class org.jboss.cache.interceptors.NotificationInterceptor >>>> class org.jboss.cache.interceptors.TxInterceptor >>>> class org.jboss.cache.interceptors.CacheMgmtInterceptor >>>> class org.jboss.cache.interceptors.InvocationContextInterceptor >>>> 2007-10-23 14:28:34,806 DEBUG >>>> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Not >>>> using >>>> an EvictionPolicy >>>> 2007-10-23 14:28:34,815 DEBUG >>>> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] cache >>>> mode is REPL_ASYNC >>>> 2007-10-23 14:28:34,815 DEBUG >>>> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] >>>> Created >>>> Multiplexer Channel for cache cluster DefaultPartition-ClusteredSS >>>> OCache using stack udp >>>> 2007-10-23 14:28:34,844 DEBUG >>>> [org.jboss.cache.marshall.VersionAwareMarshaller] Initialised with >>>> version 2.0.0 and versionInt 20 >>>> 2007-10-23 14:28:34,844 DEBUG >>>> [org.jboss.cache.marshall.VersionAwareMarshaller] Using default >>>> marshaller class org.jboss.cache.marshall.CacheMarshaller200 >>>> 2007-10-23 14:28:34,844 DEBUG >>>> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Using >>>> marshaller org.jboss.cache.marshall.VersionAwareMarshaller >>>> 2007-10-23 14:28:34,845 DEBUG >>>> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Block >>>> received at 127.0.0.1:32787 >>>> 2007-10-23 14:28:34,899 DEBUG >>>> [org.jboss.cache.interceptors.InvocationContextInterceptor] >>>> Invoked on >>>> cache instance [127.0.0.1:32787] and InvocationContext [Invocation >>>> Context{methodCall=MethodName: _block; MethodIdInteger: 43; Args: >>>> ()transaction=null, globalTransaction=null, >>>> optionOverrides=Option{failSilently=false, cacheModeLocal >>>> =false, dataVersion=null, suppressLocking=false, >>>> forceDataGravitation=false, skipDataGravitation=false}, >>>> originLocal=true, txHasMods=false}] >>>> 2007-10-23 14:28:34,899 DEBUG >>>> [org.jboss.cache.interceptors.InvocationContextInterceptor] >>>> Setting up >>>> transactional context. >>>> 2007-10-23 14:28:34,899 DEBUG >>>> [org.jboss.cache.interceptors.InvocationContextInterceptor] >>>> Setting tx >>>> as null and gtx as null >>>> 2007-10-23 14:28:34,900 DEBUG >>>> [org.jboss.cache.interceptors.ReplicationInterceptor] >>>> isLocalCommitOrRollback? false; gtx = null >>>> 2007-10-23 14:28:34,900 DEBUG >>>> [org.jboss.cache.interceptors.PessimisticLockInterceptor] >>>> PessimisticLockInterceptor invoked for method MethodName: _block; >>>> MethodIdInteg >>>> er: 43; Args: () >>>> 2007-10-23 14:28:34,900 DEBUG >>>> [org.jboss.cache.interceptors.PessimisticLockInterceptor] bypassed >>>> locking as method _block() doesn't require locking >>>> 2007-10-23 14:28:34,900 DEBUG >>>> [org.jboss.cache.interceptors.CallInterceptor] Passing up method >>>> MethodName: _block; MethodIdInteger: 43; Args: () so it gets >>>> invoked on cache. >>>> 2007-10-23 14:28:34,900 DEBUG >>>> [org.jboss.cache.interceptors.UnlockInterceptor] Attempting to >>>> release >>>> locks on current thread. Lock table is {} >>>> 2007-10-23 14:28:34,900 DEBUG >>>> [org.jboss.cache.interceptors.ReplicationInterceptor] Non-tx and non >>>> crud meth >>>> 2007-10-23 14:28:34,900 DEBUG >>>> [org.jboss.cache.interceptors.InvocationContextInterceptor] Resetting >>>> invocation-scope options >>>> 2007-10-23 14:28:34,900 DEBUG >>>> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] Block >>>> processed at 127.0.0.1:32787 >>>> 2007-10-23 14:28:34,902 INFO >>>> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] >>>> viewAccepted(): [127.0.0.1:32787|0] [127.0.0.1:32787] >>>> 2007-10-23 14:28:34,902 DEBUG >>>> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] >>>> UnBlock >>>> received at 127.0.0.1:32787 >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.interceptors.InvocationContextInterceptor] >>>> Invoked on >>>> cache instance [127.0.0.1:32787] and InvocationContext [Invocation >>>> Context{methodCall=MethodName: _unblock; MethodIdInteger: 44; Args: >>>> ()transaction=null, globalTransaction=null, >>>> optionOverrides=Option{failSilently=false, cacheModeLoc >>>> al=false, dataVersion=null, suppressLocking=false, >>>> forceDataGravitation=false, skipDataGravitation=false}, >>>> originLocal=true, txHasMods=false}] >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.interceptors.InvocationContextInterceptor] >>>> Setting up >>>> transactional context. >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.interceptors.InvocationContextInterceptor] >>>> Setting tx >>>> as null and gtx as null >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.interceptors.ReplicationInterceptor] >>>> isLocalCommitOrRollback? false; gtx = null >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.interceptors.PessimisticLockInterceptor] >>>> PessimisticLockInterceptor invoked for method MethodName: _unblock; >>>> MethodIdInt >>>> eger: 44; Args: () >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.interceptors.PessimisticLockInterceptor] bypassed >>>> locking as method _unblock() doesn't require locking >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.interceptors.CallInterceptor] Passing up method >>>> MethodName: _unblock; MethodIdInteger: 44; Args: () so it gets >>>> invoked o >>>> n cache. >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.interceptors.UnlockInterceptor] Attempting to >>>> release >>>> locks on current thread. Lock table is {} >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.interceptors.ReplicationInterceptor] Non-tx and non >>>> crud meth >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.interceptors.InvocationContextInterceptor] Resetting >>>> invocation-scope options >>>> 2007-10-23 14:28:34,903 DEBUG >>>> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] >>>> UnBlock >>>> processed at 127.0.0.1:32787 >>>> 2007-10-23 14:28:34,903 INFO >>>> [org.jboss.cache.CacheImpl.DefaultPartition-ClusteredSSOCache] >>>> CacheImpl >>>> local address is 127.0.0.1:32787 >>>> >>>> Got bored waiting here. ;-) >>>> >>>> 2007-10-23 14:32:30,094 INFO >>>> [org.jboss.bootstrap.microcontainer.ServerImpl] JBoss SHUTDOWN >>>> >>>> >>>> There's no JBoss Cache logging before this, only some generic >>>> clustering logging (I've included where jms is using clustering >>>> but otherwise stripped its logging): >>>> >>>> >>>> 2007-10-23 14:28:27,360 DEBUG [org.jboss.system.ServiceController] >>>> starting service jboss.jgroups:service=MultiplexerChannelFactory >>>> 2007-10-23 14:28:27,360 DEBUG [org.jboss.system.ServiceController] >>>> Registering service jboss.jgroups:service=MultiplexerChannelFactory >>>> 2007-10-23 14:28:27,364 DEBUG >>>> [org.jboss.ha.framework.server.JChannelFactory] Ignoring create call; >>>> current state is Stopped >>>> >>>> ... >>>> >>>> 2007-10-23 14:28:27,367 DEBUG >>>> [org.jboss.ha.framework.server.JChannelFactory] Starting >>>> JChannelFactory >>>> 2007-10-23 14:28:27,367 DEBUG >>>> [org.jboss.ha.framework.server.JChannelFactory] Started >>>> JChannelFactory >>>> 2007-10-23 14:28:27,368 DEBUG >>>> [org.jboss.messaging.core.jmx.MessagingPostOfficeService] Starting >>>> jboss.messaging:service=PostOffice >>>> 2007-10-23 14:28:27,378 DEBUG >>>> [org.jboss.messaging.core.jmx.MessagingPostOfficeService] >>>> org.jboss.messaging.core.jmx.MessagingPostOfficeService@14b7042 uses >>>> Multiplexe >>>> rJChannelFactory >>>> >>>> 2007-10-23 14:28:28,110 DEBUG >>>> [org.jboss.ha.framework.server.JChannelFactory] Passing unique >>>> node id >>>> 127.0.0.1:1099 to the channel as additional data >>>> 2007-10-23 14:28:28,121 DEBUG >>>> [org.jboss.ha.framework.server.JChannelFactory] Passing unique >>>> node id >>>> 127.0.0.1:1099 to the channel as additional data >>>> 2007-10-23 14:28:28,214 INFO [STDOUT] >>>> ------------------------------------------------------- >>>> GMS: address is 127.0.0.1:32786 >>>> ------------------------------------------------------- >>>> 2007-10-23 14:28:30,306 DEBUG >>>> [org.jboss.messaging.core.impl.postoffice.GroupMember] >>>> org.jboss.messaging.core.impl.postoffice.GroupMember >>>> $ControlMembershipListener@334 >>>> cb9 got new view [127.0.0.1:32786|0] [127.0.0.1:32786], old view >>>> is null >>>> 2007-10-23 14:28:30,386 DEBUG >>>> [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] >>>> org.jboss.messaging.core.impl.postoffice.MessagingPostOffice@1c86116: >>>> 127. >>>> 0.0.1:32786 joined >>>> 2007-10-23 14:28:30,386 DEBUG >>>> [org.jboss.messaging.core.impl.postoffice.GroupMember] First view >>>> arrived >>>> 2007-10-23 14:28:30,387 DEBUG >>>> [org.jboss.messaging.core.impl.postoffice.GroupMember] We are the >>>> first >>>> member of the group so no need to wait for state >>>> 2007-10-23 14:28:30,391 INFO [STDOUT] >>>> ------------------------------------------------------- >>>> GMS: address is 127.0.0.1:32787 >>>> ------------------------------------------------------- >>>> 2007-10-23 14:28:32,412 DEBUG >>>> [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] >>>> Updated >>>> failover map: >>>> >>>> 0->0 >>>> >>>> 2007-10-23 14:28:32,427 DEBUG >>>> [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] >>>> org.jboss.messaging.core.impl.postoffice.MessagingPostOffice@1c86116 >>>> puts replicant locally: JVMID->6-fnu8e48f-1-yvy7e48f-0gpx6x-d24o4c5 >>>> >>>> ... >>>> >>>> 2007-10-23 14:28:32,872 DEBUG >>>> [org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint] >>>> updateClusteredClients being called!!! >>>> clientFactoriesToUpdate.size = 0 >>>> >>>> ,,, >>>> >>>> 2007-10-23 14:28:34,335 DEBUG >>>> [org.jboss.jms.server.connectionfactory.ConnectionFactory] Started >>>> jboss.messaging.connectionfactory:service=ConnectionFactory >>>> 2007-10-23 14:28:34,336 DEBUG >>>> [org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback] >>>> >>>> Registered MBean jboss.jgroups:service=MultiplexerChannelFactory >>>> 2007-10-23 14:28:34,337 DEBUG >>>> [org.jboss.ha.framework.server.JChannelFactory] Ignoring create call; >>>> current state is Started >>>> 2007-10-23 14:28:34,337 DEBUG >>>> [org.jboss.ha.framework.server.JChannelFactory] Ignoring start call; >>>> current state is Started >>>> >>> >> >

I checked out the Beta4 tag and built the assembly. I've added it to the repository, so we're just waiting for the mirroring to catch up so we can test it. For some reason the assembly name has been changed to jboss-integration-parent.jar ?????? build/pom.xml <artifactId>jboss-integration-parent</artifactId> <version>5.0.0.Beta4</version> I've got no idea what is going on with this crap? Why can't people just leave things alone when they are working? Or if you are going to play around, do a proper standup test like a full clean checkout! On Fri, 2007-10-19 at 15:56 +0200, Adrian wrote: > Somebody's broken the integration project release. > > There should be a jboss-integration.jar maven assembly. > See build/build-distr.xml > > It was there in beta3 > http://repository.jboss.com/jboss/integration/5.0.0.Beta3/component-info.xml > > but the structure of this release has been totally changed in beta4 > http://repository.jboss.com/jboss/integration/5.0.0.Beta4/component-info.xml > > There's no assembly any more????? > > On Fri, 2007-10-19 at 16:23 +0300, Dimitris Andreadis wrote: >> The testsuite runs of AS5 fail: >> https://hudson.jboss.org/hudson/job/JBoss-AS-5.0.x-TestSuite-sun15-noip/95/ >> >> It cannot instantiate the transaction manager due to missing org/jboss/tm/JBossXATerminator. >> >> It's weird because the 'all' config boots manually. >> >> The missing class is in the jboss-integration.jar > It will boot manually if you previously downloaded the > integration beta3 release. > The build-thirdparty.xml does not delete old jars so > you will still have it in thirdparty. > > It won't build manually if you "rm -rf thirdparty" :-)

Do we still need to have a combined jboss-integration.jar? Or is it ok to just include the modules that are needed?

Hi Adrian, I notice that you mentioned a 5.0.0.Beta4 release being in progress. I have been using AS trunk to get some of the WS functionality that was in Beta3 but missing from Beta2. Is there a stable(-ish :) tagged Beta3 release I can use? I don't see anything in the AS svn tags directory. regards, Andrew Dinn ----------- Adrian wrote: > I checked out the Beta4 tag and built the assembly. > > I've added it to the repository, so we're just waiting > for the mirroring to catch up so we can test it. > > For some reason the assembly name has been changed to > jboss-integration-parent.jar ?????? > > build/pom.xml > <artifactId>jboss-integration-parent</artifactId> > <version>5.0.0.Beta4</version> > > I've got no idea what is going on with this crap? > > Why can't people just leave things alone when they are > working? Or if you are going to play around, do a proper > standup test like a full clean checkout! > > On Fri, 2007-10-19 at 15:56 +0200, Adrian wrote: >> Somebody's broken the integration project release. >> >> There should be a jboss-integration.jar maven assembly. >> See build/build-distr.xml >> >> It was there in beta3 >> http://repository.jboss.com/jboss/integration/5.0.0.Beta3/component-info.xml >> >> but the structure of this release has been totally changed in beta4 >> http://repository.jboss.com/jboss/integration/5.0.0.Beta4/component-info.xml >> >> There's no assembly any more????? >> >> On Fri, 2007-10-19 at 16:23 +0300, Dimitris Andreadis wrote: >>> The testsuite runs of AS5 fail: >>> https://hudson.jboss.org/hudson/job/JBoss-AS-5.0.x-TestSuite-sun15-noip/95/ >>> >>> It cannot instantiate the transaction manager due to missing org/jboss/tm/JBossXATerminator. >>> >>> It's weird because the 'all' config boots manually. >>> >>> The missing class is in the jboss-integration.jar >> It will boot manually if you previously downloaded the >> integration beta3 release. >> The build-thirdparty.xml does not delete old jars so >> you will still have it in thirdparty. >> >> It won't build manually if you "rm -rf thirdparty" :-)