9:58 a.m.
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.
Adrian, has some kind of parallelization of deployment been introduced?
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.)
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? :-)
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com