[JBoss-dev] [ jboss-Bugs-780914 ] ClassLoader resource issue with unpacked archives
Bugs item #780914, was opened at 2003-07-31 08:18
Message generated for change (Settings changed) made by starksm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=780914&group_id=22866
Category: JBossMX
>Group: v3.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Srivatsan (srivatsanp)
Assigned to: Scott M Stark (starksm)
>Summary: ClassLoader resource issue with unpacked archives
Initial Comment:
Hi,
In JBoss 3.2.1, if any of the compressed deployment
archive contains any resource present in a
directory(say dtd/), then when some other archive has
some resource in the same "dtd/" directory, it is not
accessible.
For e.g.,
Consider the following packaging structure:
Test.sar
--dtd/Test.dtd
Application1.ear
--dtd/Test1.dtd
Application2.ear
--Test.sar
(This service is not able to access the Test1.dtd
present in Application1.ear).
The dtd is accessed using
this.getClass().getClassLoader().getResource("dtd/Test1.dtd");
If Test.sar is deployed as an unpacked archive, the
Test1.dtd is accessible.
This is due to a bug in indexing in ClassLoaderUtils.java
If the deployment unit is unpacked, it indexes the
package names of the class file only.
If the deployment unit is a compressed archive, it
indexes all the entries present in the archive. This
results in indexing of the dtd directory present in
Test.sar. So when getResource("dtd/Test1.dtd") is
performed, the dtd is searched only in Test.sar.
--
>Comment By: Scott M Stark (starksm)
Date: 2003-08-05 07:44
Message:
Logged In: YES
user_id=175228
The .class filter has been removed as this was preventing
indexing of directories without any class files. As an
intermediate workaround put an empty x.class file in the
resource directory. The test now finds all resources:
07:41:47,300 INFO [MyTest] Starting
07:41:47,310 INFO [STDOUT] startService**
07:41:47,320 INFO [STDOUT]
URL1jar:file:/C:/cvs/JBoss3.2/jboss-3.2/build/output/jboss-3
.2.2RC3/server/780914/tmp/deploy/tmp24002ear1.ear!/conf/testing.xml
07:41:47,340 INFO [STDOUT]
URL2file:/C:/cvs/JBoss3.2/jboss-3.2/build/output/jboss-3.2.2
RC3/server/780914/deploy/ear2.ear/conf/test.xml
07:41:47,360 INFO [STDOUT]
URL2file:/C:/cvs/JBoss3.2/jboss-3.2/build/output/jboss-3.2.2
RC3/server/780914/deploy/ear3.ear/conf/aatesting.xml
07:41:47,391 INFO [STDOUT] Context classloader =
[EMAIL PROTECTED]
url=file:/C:/cvs/JBoss3.2/jboss-3.2/build/output/jboss-3.2.2RC3/server/780914/deploy/ear4.ear/
,addedOrder=30}
07:41:47,411 INFO [MyTest] Started
--
Comment By: Srivatsan (srivatsanp)
Date: 2003-08-03 22:32
Message:
Logged In: YES
user_id=687037
Please find the attached zip which contains four ears:
ear1.ear -- compressed archive
ear2.ear, ear3.ear, ear4.ear -- unpacked deployments
The ear4.ear contains a service which gets the Resources using,
this.getClass().getClassLoader().getResource("conf/testing.xml")
this.getClass().getClassLoader().getResource("conf/test.xml")
this.getClass().getClassLoader().getResource("conf/aatesting.xml")
The source for the service is also attached.
Deploy the ears in the order: ear1.ear, ear2.ear, ear3.ear,
ear4.ear.
--
Comment By: Scott M Stark (starksm)
Date: 2003-08-01 13:03
Message:
Logged In: YES
user_id=175228
I have updated the resource loading unit test to include
exactly the configuration you indicate and I have no problem
loading the dtd resource with 3.2.1. Reopen with a testcase
that demonstrates the issue and look at the
org.jboss.test.classloader.test.UnifiedLoaderUnitTestCase.testUnpackedResources
case.
--
Comment By: Srivatsan (srivatsanp)
Date: 2003-08-01 01:01
Message:
Logged In: YES
user_id=687037
Is there any workaround for this? Is there a configuration
for ignoring the indexing mechanism?
--
Comment By: Srivatsan (srivatsanp)
Date: 2003-07-31 22:29
Message:
Logged In: YES
user_id=687037
Forgot to mention that Application1.ear and Application2.ear
are unpaccked deployments.
Application1.ear/
dtd/Test1.dtd
Application2.ear/
Test.sar
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=780914&group_id=22866
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
__
Re: [JBoss-dev] jboss-3.2/tomcat module updated
The same now also applies to jboss-head. -- Scott Stark Chief Technology Officer JBoss Group, LLC Scott M Stark wrote: The jboss-3.2 cvs structure has been updated to drop the obsolete catalina subdir and rename the tomcat41 to tomcat so that the tc4.1 and tc5.0 services may be integrated into one source tree. You will need to obtain a clean checkout as the cvs module definitions have changed. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DistributedReplicantManager.isMasterReplica(String)false positives?
But what is the nameservice for these 'logical' names, and what layer uses them? -- Scott Stark Chief Technology Officer JBoss Group, LLC Bela Ban wrote: Yes I agree. What Sacha referred to, however, was the fact that you can have 'logical' names rather than host:port as member addresses. This is useful if a member is shunned, leaves and rejoins the group under a different host:port address. The logical name would remain the same in this case. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-762045 ] Cannot get EJB Home interface from Remote interface
Bugs item #762045, was opened at 2003-06-27 12:12
Message generated for change (Comment added) made by starksm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=762045&group_id=22866
Category: JBossServer
Group: v3.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dan Ciarniello (dciarnie)
>Assigned to: Scott M Stark (starksm)
Summary: Cannot get EJB Home interface from Remote interface
Initial Comment:
One cannot get an EJB home interface from a remote
interface (using getEJBHome()) when the JNDI connection
properties are not set in the System property space.
The following code fragment illustrates the problem:
==
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY,"org.jnp.interfaces.NamingContextFactory");
// host must be remote, not local
props.setProperty(Context.PROVIDER_URL,"remotehost:1099");
props.setProperty(Context.URL_PKG_PREFIXES,"org.jboss.naming");
InitialContext ctx = new InitialContext(props);
FooHome foohome = (FooHome)ctx.lookup("ejb/foohome");
Foo foo = foo.findByPrimaryKey(id);
EJBHome home = foo.getEJBHome();
==
The last line will fail with a
java.lang.reflect.UndeclaredThrowableException caused
by a java.net.SocketTimeoutException.
I have traced the problem to
org.jboss.proxy.ejb.GenericEJBInterceptor.getEJBHome(Invocation).
which has the line
InitialContext iniCtx = new InitialContext();
and therein lies the problem. This assumes that the
JNDI connection properties have been set in the System
property space which is not the case in the above example.
The remote interface must have explicit access to the
JNDI properties used to retrieve it in the first place.
It cannot assume that these properties have been set
in the System property space.
Note that this problem also exists in v3.2. It does
not exist in 2.4.x.
--
>Comment By: Scott M Stark (starksm)
Date: 2003-08-05 14:27
Message:
Logged In: YES
user_id=175228
The home is taken from the proxy context which was created
on the server and now has no reliance on the client side
naming environment.
--
Comment By: Dan Ciarniello (dciarnie)
Date: 2003-08-05 09:30
Message:
Logged In: YES
user_id=529841
Changing group to 3.2 since no one is responding to it
marked as 3.0 and it still exists in 3.2.2.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=762045&group_id=22866
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-780746 ] Unable to passivate due
Bugs item #780746, was opened at 2003-07-31 19:55 Message generated for change (Comment added) made by scoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=780746&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Meyer (mmrmichael) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to passivate due Initial Comment: OS : Linux JDK : 1.4.2 JBoss Version : 3.2.2 RC1 I got the following error (on console) : WARN [AbstractInstanceCache] Unable to passivate due to ctx lock, id = xxx. The result of this error is the complete use of memory and I have to restart the server. Michael Meyer -- Comment By: Stephen Coy (scoy) Date: 2003-08-05 18:18 Message: Logged In: YES user_id=463096 I am seeing these in a 3.2.2RC3 build after an EJBException was thrown from a SLSB through a CMP 2.0 entity bean - causing a transaction rollback. Transaction locks are not being released following an exception somewhere. Further attempts to access the entity result in a hang at: "Thread-5" daemon prio=5 tid=0x03fbf620 nid=0x5373c10 runnable [f098e000..f0992b70] at java.lang.Object.wait(Native Method) - waiting on <0x670faf88> (a org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock$TxLock) at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.waitForTx(Qu euedPessimisticEJBLock.java:301) - locked <0x670faf88> (a org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock$TxLock) at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.doSchedule(Q ueuedPessimisticEJBLock.java:209) at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.schedule(Que uedPessimisticEJBLock.java:157) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterc eptor.java:85) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreati onInterceptor.java:53) at org.jboss.ejb.plugins.AbstractInterceptor.invoke(AbstractIntercepto r.java:94) ... This particular entity is configured to use "Commit Option A" for what it is worth. After a while I see the "Unable to passivate..." warnings from other related (thru CMR) entities that were implicated in the original transaction. -- Comment By: Scott M Stark (starksm) Date: 2003-08-02 12:50 Message: Logged In: YES user_id=175228 Yes, but the testcases causing these are largely exceptional cases and do not neccessarily result in leaks. -- Comment By: Stefan Reich (sreich) Date: 2003-08-02 08:20 Message: Logged In: YES user_id=429729 When you run the test suite you will find several similar warnings in the log files. -- Comment By: Scott M Stark (starksm) Date: 2003-08-02 03:11 Message: Logged In: YES user_id=175228 That does not help. Describe the use cases of the stateful session bean that are leading to its passiviation with a tx lock and include the full stacktraces of the failure. -- Comment By: Michael Meyer (mmrmichael) Date: 2003-08-01 17:33 Message: Logged In: YES user_id=605914 We are running MySql 4.1 MAX as backend and inside the jetty container we are running cocoon (latest version 2.1) -- Comment By: Scott M Stark (starksm) Date: 2003-08-01 00:39 Message: Logged In: YES user_id=175228 Provide an testcase or at least some context for this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=780746&group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-577711 ] getEJBObject needs ProxyFactory
Bugs item #577711, was opened at 2002-07-05 12:25 Message generated for change (Comment added) made by loubyansky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=577711&group_id=22866 Category: JBossServer Group: v3.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Carsten Teich (cteich) >Assigned to: Alexey Loubyansky (loubyansky) Summary: getEJBObject needs ProxyFactory Initial Comment: When Accessing the remote interface within a Bean i get the following Exception: 2002-07-05 10:51:13,525 DEBUG [org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor] invokerBInding is null in ProxyFactoryFinder 2002-07-05 10:51:13,535 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException, causedBy: java.lang.IllegalStateException: No remote interface defined. at org.jboss.ejb.EntityEnterpriseContext$EntityContextImpl.getEJBObject(EntityEnterpriseContext.java:184) at de.bmiag.kredit.entity.entity1.Entity1Bean.getRemote(Entity1Bean.java:67) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1094) at org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor.invoke(JDBCRelationInterceptor.java:95) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:308) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionIntercepto r.java:186) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:152) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:107) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:108) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:181) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:481) at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:351) at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38) at $Proxy34.getRemote(Unknown Source) at de.bmiag.kredit.po.PO1Bean.test1(PO1Bean.java:44) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invoke(StatefulSessionContainer.java:835) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionIntercepto r.java:186) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:2 68) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:108) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:181) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:370) at org.jboss.ejb.Container.invoke(Container.java:674) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:321) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run(Transport.java:152) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706) at java.lang.Thread.run(Thread.java:484) 2002-07-05 10:51:13,815 INFO [STDOUT] Fehler!!javax.ejb.TransactionRolledbackLocalException: No remote interface defined.; CausedByException is: No remote interface defined. This occurs only if no remote interface was used before. When I create a second Bean and retrieve the remote interface by PrimaryKey I can then ask the first Bean for its remo
[JBoss-dev] 광고)저렴한 특별 기획상품을 소개 합니다!
Title: 새 페이지 1 [EMAIL PROTECTED]<][,9|=)TXv?5/v --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] DistributedReplicantManager.isMasterReplica(String) false positives?
Hello Bela,
Yes, but Scott found two interesting things:
- it seems that even if two nodes share the same view, the name of the
members of the view may appear different (one has the name, the other the IP
address)
- there is an unstable condition somewhere that make the singleton service
flip-flap while it shouldn't be necessary (+ race condition but that's at
another level)
I will most probably play with the additional code you had added at the
begginig of the year to add another information to the IpAddress, but for
this will have to change TCP as well (you only changed UDP) so that this
additional information is always taken in account when generating new
IpAddress at the TCP JG protocol layer.
Cheers,
Sacha
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Bela Ban
> Sent: lundi, 4. août 2003 23:55
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev]
> DistributedReplicantManager.isMasterReplica(String) false positives?
>
>
> The entire logic to determine when to become singleton is
> handled in the
> view callback. Since this can potentially be length, and also uses
> remote group calls, I suggest to run this in a separate
> thread, so you
> won't run into a deadlock. By default, HA Clustering does *not* use
> deadlock detection.
>
>
> Scott M Stark wrote:
>
> > There is a race condition i the
> > DistributedReplicantManager.isMasterReplica(String) that
> shows up when
> > this method is called from within a notifyKeyListeners as shown by
> > this stack trace:
> >
> > Thread "main"@65 status: RUNNING
> > - isMasterReplica():437,
> > org.jboss.ha.framework.server.DistributedReplicantManagerImpl
> > - isDRMMasterReplica():234, org.jboss.ha.jmx.HAServiceMBeanSupport
> > - partitionTopologyChanged():103,
> > org.jboss.ha.singleton.HASingletonSupport
> > - replicantsChanged():197, org.jboss.ha.jmx.HAServiceMBeanSupport$1
> > - notifyKeyListeners():675,
> > org.jboss.ha.framework.server.DistributedReplicantManagerImpl
> > - add():326,
> > org.jboss.ha.framework.server.DistributedReplicantManagerImpl
> > - registerDRMListener():204, org.jboss.ha.jmx.HAServiceMBeanSupport
> > - startService():144, org.jboss.ha.jmx.HAServiceMBeanSupport
> >
> > This is due the the choice to return true when the key in
> question is
> > in the
> > localReplicants table, but not the replicants table:
> >
> >public boolean isMasterReplica (String key)
> >{
> > if (!localReplicants.containsKey (key))
> > return false;
> >
> > Vector allNodes = this.partition.getCurrentView ();
> > HashMap repForKey = (HashMap)replicants.get(key);
> > if (repForKey==null)
> > return true;
> >
> > This seems to be an ambiguous condition as this condition
> exists for a
> > node that calls add and when the state has not synched or
> has failed
> > to synch. Another problem I'm seeing at least in the context of the
> > singleton service is that the notion of the master node is
> unstable.
> > Here is the output from one of 3 nodes running the
> singleton service
> > starting with the addition of the final node shown as view 2.
> >
> > 15:35:44,637 INFO [Server] JBoss (MX MicroKernel)
> [3.2.2RC3 (build:
> > CVSTag=Branch_3_2 date=200307312219)] Started in 5s:948ms
> > 15:36:27,719 INFO [DefaultPartition] New cluster view: 2
> > ([lamia:32947, 172.17.66.54:2821, ironmaiden:51770] delta: 1)
> > 15:36:27,749 INFO [DefaultPartition:ReplicantManager] Dead
> members: 0
> > 15:37:13,555 INFO [DefaultPartition] New cluster view (id:
> 3, delta:
> > -1) : [172.17.66.54:2821, ironmaiden:51770]
> > 15:37:13,575 INFO [DefaultPartition:ReplicantManager] Dead
> members: 1
> > 15:38:13,321 INFO [HASingletonMBeanExample] Notified to start as
> > singleton
> > 15:38:13,321 INFO [DefaultPartition] New cluster view (id:
> 4, delta:
> > 1) : [172.17.66.54:2821, ironmaiden:51770, lamia:32949]
> > 15:38:13,331 INFO [DefaultPartition:ReplicantManager] Dead
> members: 0
> > 15:38:13,361 INFO [HASingletonMBeanExample] Notified to stop as
> > singleton
> > 15:39:13,447 INFO [HASingletonMBeanExample] Notified to start as
> > singleton
> > 15:39:13,457 INFO [HASingletonMBeanExample] Notified to stop as
> > singleton
> >
> > With view 3 the orginal node and singleton is killed and
> the node for
> > which the console output corresponds(172.17.66.54) is
> selected as the
> > singleton. When the third node is started again there is some
> > thrashing due to the existing 2 nodes both selecting
> themselves as the
> > singleton and telling the other to stop and it appears that
> there is
> > no singleton choosen. The problem seems to be inconsistent
> matching
> > of member names. Once only knows it IP while the other node
> knows the
> > hostnames. Here is the console view of the second node showing the
> > hostnames and its thrashing:
> >
> > 15:25:21,023 INFO [Server] JBoss (MX
