[JBoss JIRA] (JGRP-1447) JGroups Address UUID problem
by Mitchell Ackerman (JIRA)
Mitchell Ackerman created JGRP-1447:
---------------------------------------
Summary: JGroups Address UUID problem
Key: JGRP-1447
URL: https://issues.jboss.org/browse/JGRP-1447
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.8
Environment: JBoss 7.0.2, Infinispan 5.1.3.FINAL, Java 1.6.30, CentOS 6.2, Amazon Cloud instances
Reporter: Mitchell Ackerman
Assignee: Bela Ban
Hi, I have a problem with the ViewChanged notification providing a 'wrong' address. In general, addresses are provided in the following format, e.g., ip-10-81-128-189-29581, but occassionally we see UUID like addresses 0fbd6496-9b37-f2ca-3c93-590d6b54324e. We are then attempting to convert this to an IP address using JGroups, which fails
DefaultCacheManager dcm = (DefaultCacheManager)CacheManager.getInstance().getCacheManager();
JGroupsTransport jgt = (JGroupsTransport)dcm.getTransport();
Object addr = jgt.getChannel().getProtocolStack().down(new Event(Event.GET_PHYSICAL_ADDRESS, ((JGroupsAddress)jgroupsAddress).getJGroupsAddress()));
This is occurring in a cluster with 3+ members, and when a member joins, one other member of the cluster will often get an address as above. Subsequently, if another node joins the cluster, the cluster view that originally received the UUID address will then have the address of that node (represented by the UUID) in the normal format.
Is this a bug? if not, how can the UUID address be converted to an IP address?
Our environment is:
CentOS 6.2
We are using a GossipRouter to manage our cluster.
Infinispan 5.1.3.FINAL (JGroups 3.0.8.FINAL).
Java 1.6.30
I know that this is occurring via Infinispan, but it looks like a JGroups issue.
Our gossip router config is:
<?xml version="1.0" encoding="UTF-8"?>
<config>
<TCP bind_port="7900"/>
<TCPGOSSIP timeout="3000" initial_hosts="10.81.0.227[8800]" num_initial_members="3"/>
<MERGE2 max_interval="30000" min_interval="10000"/>
<FD_SOCK/>
<FD timeout="10000" max_tries="5"/>
<VERIFY_SUSPECT timeout="1500"/>
<pbcast.NAKACK use_mcast_xmit="false" retransmit_timeout="300,600,1200,2400,4800" discard_delivered_msgs="true"/>
<UNICAST timeout="300,600,1200,2400,3600"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000" view_bundling="true"/>
<UFC max_credits="2000000" min_threshold="0.10"/>
<MFC max_credits="2000000" min_threshold="0.10"/>
<FRAG2 frag_size="60000"/>
</config>
Here is some pared down logging from our servers:
10.81.0.227
2012-04-11 22:17:58,123 [notification-thread-0] INFO [JmsCluster.viewChanged() 375] - ip-10-81-128-189-29581 [NODE|ATTACHED]
2012-04-11 22:17:58,125 [notification-thread-0] INFO [JmsCluster.getInetAddress() 457] - getInetAddress ip-10-81-128-189-29581 => 10.81.128.189
2012-04-11 22:18:20,054 [notification-thread-0] INFO [JmsCluster.viewChanged() 388] - ip-10-81-208-97-19626 [NODE|DETACHED]
2012-04-11 22:18:20,073 [notification-thread-0] INFO [JmsCluster.getInetAddress() 457] - getInetAddress ip-10-81-208-97-19626 => 10.81.208.97
2012-04-11 22:18:45,515 [notification-thread-0] INFO [JmsCluster.viewChanged() 375] - ip-10-81-208-97-20403 [NODE|ATTACHED]
2012-04-11 22:18:45,518 [notification-thread-0] INFO [JmsCluster.getInetAddress() 457] - getInetAddress ip-10-81-208-97-20403 => 10.81.208.97
10.81.128.189
2012-04-11 22:18:04,686 [notification-thread-0] INFO [JmsCluster.viewChanged() 375] - ip-10-81-128-189-29581 [NODE|ATTACHED]
2012-04-11 22:18:04,689 [notification-thread-0] INFO [JmsCluster.getInetAddress() 457] - getInetAddress ip-10-81-128-189-29581 => 10.81.128.189
2012-04-11 22:18:20,402 [notification-thread-0] INFO [JmsCluster.viewChanged() 388] - ip-10-81-208-97-19626 [NODE|DETACHED]
2012-04-11 22:18:20,404 [notification-thread-0] INFO [JmsCluster.getInetAddress() 457] - getInetAddress ip-10-81-208-97-19626 => 10.81.208.97
2012-04-11 22:18:45,640 [notification-thread-0] INFO [JmsCluster.viewChanged() 375] - 0fbd6496-9b37-f2ca-3c93-590d6b54324e [NODE|ATTACHED]
2012-04-11 22:18:45,640 [notification-thread-0] INFO [JmsCluster.getInetAddress() 437] - getInetAddress 0fbd6496-9b37-f2ca-3c93-590d6b54324e
2012-04-11 22:18:45,641 [notification-thread-0] INFO [JmsCluster.getInetAddress() 441] - getInetAddress, DefaultCacheManager view: members: [ip-10-81-0-227-2930, ip-10-81-128-189-29581, 0fbd6496-9b37-f2ca-3c93-590d6b54324e]
2012-04-11 22:18:45,641 [notification-thread-0] INFO [JmsCluster.getInetAddress() 444] - getInetAddress, JGroupsTransport view: members: [ip-10-81-0-227-2930, ip-10-81-128-189-29581, 0fbd6496-9b37-f2ca-3c93-590d6b54324e], addresses: [10.81.128.189:7800]
2012-04-11 22:18:45,642 [notification-thread-0] INFO [JmsCluster.getInetAddress() 457] - getInetAddress 0fbd6496-9b37-f2ca-3c93-590d6b54324e => null
2012-04-11 22:37:05,509 [notification-thread-0] INFO [JmsCluster.viewChanged() 388] - ip-10-81-0-227-2930 [NODE|DETACHED]
2012-04-11 22:37:05,512 [notification-thread-0] INFO [JmsCluster.getInetAddress() 437] - getInetAddress ip-10-81-0-227-2930
2012-04-11 22:37:05,512 [notification-thread-0] INFO [JmsCluster.getInetAddress() 441] - getInetAddress, DefaultCacheManager view: members: [ip-10-81-128-189-29581, ip-10-81-208-97-20403]
2012-04-11 22:37:05,513 [notification-thread-0] INFO [JmsCluster.getInetAddress() 444] - getInetAddress, JGroupsTransport view: members: [ip-10-81-128-189-29581, ip-10-81-208-97-20403], addresses: [10.81.128.189:7800]
2012-04-11 22:37:05,514 [notification-thread-0] INFO [JmsCluster.getInetAddress() 457] - getInetAddress ip-10-81-0-227-2930 => 10.81.0.227
the later logging shows that 0fbd6496-9b37-f2ca-3c93-590d6b54324e represents ip-10-81-208-97-20403
10.81.208.97
2012-04-11 22:18:53,257 [notification-thread-0] INFO [JmsCluster.viewChanged() 375] - ip-10-81-208-97-20403 [NODE|ATTACHED]
2012-04-11 22:18:53,260 [notification-thread-0] INFO [JmsCluster.getInetAddress() 457] - getInetAddress ip-10-81-208-97-20403 => 10.81.208.97
2012-04-11 22:37:18,178 [notification-thread-0] INFO [JmsCluster.viewChanged() 388] - ip-10-81-128-189-29581 [NODE|DETACHED]
2012-04-11 22:37:18,180 [notification-thread-0] INFO [JmsCluster.getInetAddress() 457] - getInetAddress ip-10-81-128-189-29581 => 10.81.128.189
Looks very like JGRP-1293, JGRP-1252
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (JGRP-1448) FILE_PING: Fail to read node file
by Peter Nerg (JIRA)
Peter Nerg created JGRP-1448:
--------------------------------
Summary: FILE_PING: Fail to read node file
Key: JGRP-1448
URL: https://issues.jboss.org/browse/JGRP-1448
Project: JGroups
Issue Type: Patch
Affects Versions: 2.12.3
Environment: Any O/S with a NFS or other type of shared file system
Reporter: Peter Nerg
Assignee: Bela Ban
Attachments: FILE_PING.java
When using the FILE_PING protocol it will periodically print the following in the log:
2012-03-19 16:20:41,057 [ Timer-5,<ADDR>] WARN [org.jgroups.protocols.FILE_PING] failed reading 83dc9dfe-8dd4-eff2-4474-d57dbaa96143.node: removing it
This is most likely due to that all members write randomly to the same directory and reading is done without any synchronization to the writes.
Hence running for long enough some point in time the read file will be corrupt.
This occurs more often the slower the shared file system is (e.g. a slow NFS mount).
I will uploaded a patch in which there are two modifications to the FILE_PING class.
1) Writing to files are done in two steps.
First we write to a temporary file in order to avoid that the "readAll" methods picks up a half written file.
Then we do a semi-atomic move of the tmp file to the proper node fil
2) Reading all node files will perform a few re-attempts should it fail to read a file.
This is to provide a simple re-try mechanism should the file be half written and therefore not readable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-3110) Enhance validation message when multiple persistence units are found
by Markus Dahm (Created) (JIRA)
Enhance validation message when multiple persistence units are found
--------------------------------------------------------------------
Key: AS7-3110
URL: https://issues.jboss.org/browse/AS7-3110
Project: Application Server 7
Issue Type: Enhancement
Reporter: Markus Dahm
Priority: Minor
The current message is
Caused by: java.lang.IllegalArgumentException: JBAS011470: Persistence unitName was not specified and there are 9 persistence unit definitions in application deployment "test.ear". Either change the application to have only one persistence unit definition or specify the unitName for each reference to a persistence unit.
Yet what is always helpful in search of such validation errors is the context.
In that case the offending class name would suffice, you should have this information at hands since you're scanning the classes, right?
Given that information I'd have found the problem immediately.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (JBBOOT-138) Failure To Start JBoss on Java 7
by Jimmy Wilson (JIRA)
Failure To Start JBoss on Java 7
--------------------------------
Key: JBBOOT-138
URL: https://issues.jboss.org/browse/JBBOOT-138
Project: JBoss Bootstrap
Issue Type: Bug
Components: legacy
Reporter: Jimmy Wilson
Assignee: Andrew Rubinger
JBoss fails to boot on Java 7:
Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/bootstrap/BaseServerConfig
at org.jboss.bootstrap.AbstractServerImpl.doInit(AbstractServerImpl.java:190)
at org.jboss.bootstrap.AbstractServerImpl.init(AbstractServerImpl.java:173)
at org.jboss.bootstrap.AbstractServerImpl.init(AbstractServerImpl.java:143)
at org.jboss.Main.boot(Main.java:218)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.ClassNotFoundException: org.jboss.bootstrap.BaseServerConfig
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4026) Hang in RemoteProxyController when remote disconnects
by Carlo de Wolf (JIRA)
Carlo de Wolf created AS7-4026:
----------------------------------
Summary: Hang in RemoteProxyController when remote disconnects
Key: AS7-4026
URL: https://issues.jboss.org/browse/AS7-4026
Project: Application Server 7
Issue Type: Bug
Components: Remoting
Reporter: Carlo de Wolf
Assignee: David Lloyd
For reasons unknown the remote endpoint disconnects:
{noformat}
11:09:42,455 ERROR (Remoting "endpoint" read-1) [org.jboss.remoting.remote.connection] <RemoteConnection.java:99> JBREM000200: Remote connection failed: java.io.IOException: Connection reset by peer
{noformat}
After which the RemoteProxyController fails to proceed:
{noformat}
"main" prio=10 tid=0x00007f0078006800 nid=0x2fb4 waiting on condition [0x00007f007f049000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007d867e8d0> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
at org.jboss.as.controller.remote.RemoteProxyController$ExecuteRequestContext.awaitPreparedOrFailed(RemoteProxyController.java:405)
at org.jboss.as.controller.remote.RemoteProxyController.execute(RemoteProxyController.java:122)
at org.jboss.as.controller.test.RemoteProxyControllerProtocolTestCase.testClosesBeforePrepare(RemoteProxyControllerProtocolTestCase.java:548)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4619) JBoss AS 7.0.2 do not start when Java Agent is run and throws log error with JVM 6 update 15 and above
by Ramesh Pa (JIRA)
Ramesh Pa created AS7-4619:
------------------------------
Summary: JBoss AS 7.0.2 do not start when Java Agent is run and throws log error with JVM 6 update 15 and above
Key: AS7-4619
URL: https://issues.jboss.org/browse/AS7-4619
Project: Application Server 7
Issue Type: Bug
Components: Class Loading
Affects Versions: 7.1.1.Final
Environment: Windows and Unix
Reporter: Ramesh Pa
Assignee: David Lloyd
Priority: Critical
Workaround as below is also not working.
set JAVA_OPTS= %JAVA_OPTS% -Xbootclasspath/p:C:\jboss-6.1.0.Final\lib\jboss-logmanager.jar -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dorg.jboss.logging.Logger .pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl
No issues with JVM 6 update 14 and earlier.
Error message
INFO: 801. Dummy Java Agent:: Transformer to Transform Class: java/lang/ExceptionInInitializerError
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.jboss.as.server.Main.main(Main.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.modules.Module.run(Module.java:272)
at org.jboss.modules.Main.main(Main.java:313)
Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system proper
ty to "org.jboss.logmanager.LogManager")
at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
... 7 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month