3:39 p.m.
This has been around for over a week without anybody fixing it,
so I guess whoever is responsible doesn't know about it?
The errors are logged when you shutdown the server
so it isn't validated by the testsuite.
15:15:34,249 ERROR [Connector] invalid Object Name
javax.management.InstanceNotFoundException:
jboss.remoting:service=invoker,transport=bisocket,host=127.0.0.1,port=4457,JBM_clientMaxPoolSize=200,clientLeasePeriod=10000,clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper,dataType=jms,marshaller=org.jboss.jms.wireformat.JMSWireFormat,numberOfCallRetries=1,numberOfRetries=10,pingFrequency=214748364,pingWindowFactor=10,socket.check_connection=false,stopLeaseOnFailure=true,timeout=0,unmarshaller=org.jboss.jms.wireformat.JMSWireFormat
is not registered.
at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
at
org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
at
org.jboss.remoting.util.SecurityUtility.unregisterMBean(SecurityUtility.java:538)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1103)
at
org.jboss.remoting.transport.Connector.destroy(Connector.java:1167)
15:15:34,302 WARN [StartStopLifecycleAction] Error during stop for
org.jboss.ejb3.RemotingConnector
java.lang.NoSuchFieldError: m_map
at
org.jboss.remoting.transport.socket.LRUPool.getContents(LRUPool.java:81)
at
org.jboss.remoting.transport.socket.SocketServerInvoker.cleanup(SocketServerInvoker.java:437)
at
org.jboss.remoting.transport.socket.SocketServerInvoker.stop(SocketServerInvoker.java:404)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1111)
15:15:38,353 ERROR [Connector] invalid Object Name
javax.management.InstanceNotFoundException:
jboss.remoting:service=invoker,transport=socket,host=127.0.0.1,port=4446,dataType=invocation,enableTcpNoDelay=true,marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller,unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller
is not registered.
at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
at
org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
at
org.jboss.remoting.util.SecurityUtility.unregisterMBean(SecurityUtility.java:538)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1103)
at
org.jboss.remoting.transport.Connector.destroy(Connector.java:1167)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
4:02 p.m.
On Thu, 2008-09-04 at 17:14 +0300, Dimitris Andreadis wrote:
I was seeing the same errors up until I cleaned up my workspace (I
think thirdparty) :-)
Hudson is showing the same errors, it does a clean checkout and build.
I always
rm -rf thirdpartry; svn update thirdparty
when somebody changes component-matrix anyway.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
4:14 p.m.
I was seeing the same errors up until I cleaned up my workspace (I think thirdparty) :-)
Adrian Brock wrote:
This has been around for over a week without anybody fixing it,
so I guess whoever is responsible doesn't know about it?
The errors are logged when you shutdown the server
so it isn't validated by the testsuite.
15:15:34,249 ERROR [Connector] invalid Object Name
javax.management.InstanceNotFoundException:
jboss.remoting:service=invoker,transport=bisocket,host=127.0.0.1,port=4457,JBM_clientMaxPoolSize=200,clientLeasePeriod=10000,clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper,dataType=jms,marshaller=org.jboss.jms.wireformat.JMSWireFormat,numberOfCallRetries=1,numberOfRetries=10,pingFrequency=214748364,pingWindowFactor=10,socket.check_connection=false,stopLeaseOnFailure=true,timeout=0,unmarshaller=org.jboss.jms.wireformat.JMSWireFormat
is not registered.
at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
at
org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
at
org.jboss.remoting.util.SecurityUtility.unregisterMBean(SecurityUtility.java:538)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1103)
at
org.jboss.remoting.transport.Connector.destroy(Connector.java:1167)
15:15:34,302 WARN [StartStopLifecycleAction] Error during stop for
org.jboss.ejb3.RemotingConnector
java.lang.NoSuchFieldError: m_map
at
org.jboss.remoting.transport.socket.LRUPool.getContents(LRUPool.java:81)
at
org.jboss.remoting.transport.socket.SocketServerInvoker.cleanup(SocketServerInvoker.java:437)
at
org.jboss.remoting.transport.socket.SocketServerInvoker.stop(SocketServerInvoker.java:404)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1111)
15:15:38,353 ERROR [Connector] invalid Object Name
javax.management.InstanceNotFoundException:
jboss.remoting:service=invoker,transport=socket,host=127.0.0.1,port=4446,dataType=invocation,enableTcpNoDelay=true,marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller,unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller
is not registered.
at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
at
org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
at
org.jboss.remoting.util.SecurityUtility.unregisterMBean(SecurityUtility.java:538)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1103)
at
org.jboss.remoting.transport.Connector.destroy(Connector.java:1167)
4:28 p.m.
On Thu, 2008-09-04 at 15:39 +0200, Adrian Brock wrote:
15:15:34,302 WARN [StartStopLifecycleAction] Error during stop for
org.jboss.ejb3.RemotingConnector
java.lang.NoSuchFieldError: m_map
at org.jboss.remoting.transport.socket.LRUPool.getContents(LRUPool.java:81)
at
org.jboss.remoting.transport.socket.SocketServerInvoker.cleanup(SocketServerInvoker.java:437)
at
org.jboss.remoting.transport.socket.SocketServerInvoker.stop(SocketServerInvoker.java:404)
at org.jboss.remoting.transport.Connector.stop(Connector.java:1111)
At a glance LRUPool extends LRUCachePolicy which has a protected m_map
field. So for the moment I would say: Uh?
Carlo
4:48 p.m.
New subject: LRUCachePolicy incompatiblity WAS Re: Remoting shutdown errors and warnings
On Thu, 2008-09-04 at 16:28 +0200, Carlo de Wolf wrote:
On Thu, 2008-09-04 at 15:39 +0200, Adrian Brock wrote:
> 15:15:34,302 WARN [StartStopLifecycleAction] Error during stop for
> org.jboss.ejb3.RemotingConnector
> java.lang.NoSuchFieldError: m_map
> at org.jboss.remoting.transport.socket.LRUPool.getContents(LRUPool.java:81)
> at
org.jboss.remoting.transport.socket.SocketServerInvoker.cleanup(SocketServerInvoker.java:437)
> at
org.jboss.remoting.transport.socket.SocketServerInvoker.stop(SocketServerInvoker.java:404)
> at org.jboss.remoting.transport.Connector.stop(Connector.java:1111)
At a glance LRUPool extends LRUCachePolicy which has a protected m_map
field. So for the moment I would say: Uh?
I've tried
rm -rf ~/.m2/repository/org/jboss/remoting/
rm -rf ~/.m2/repository/org/jboss/ejb3/
and did a clean build (including clobbering thirdparty).
Still seeing the error.
Disassembling LRUCachePolicy, I can see the
protected field m_map
$ javap -c -classpath jboss-common-core.jar
org.jboss.util.LRUCachePolicy
Compiled from "LRUCachePolicy.java"
public class org.jboss.util.LRUCachePolicy extends java.lang.Object
implements org.jboss.util.CachePolicy{
protected java.util.Map m_map;
Disassembing LRUPool, it is expecting a HashMap not a Map
so this has obviously changed at some point.
$ javap -c -classpath jboss-remoting.jar
org.jboss.remoting.transport.socket.LRUPool
Compiled from "LRUPool.java"
public class org.jboss.remoting.transport.socket.LRUPool extends
org.jboss.util.LRUCachePolicy{
...
public java.util.Set getContents();
Code:
0: aload_0
1: getfield #12; //Field m_map:Ljava/util/HashMap;
4: invokevirtual #13; //Method
java/util/HashMap.keySet:()Ljava/util/Set;
7: areturn
So JBoss Remoting needs recompiling over the latest
jboss-common-core
I don't know whether this fixes the other problems?
Carlo
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5:04 p.m.
Maybe the class loader of LRUCachePolicy is already gone?
LRUPool is coming from:
BaseClassLoader@12a7c1e{vfsfile:/home/carlo/work/jboss-head/build/output/jboss-5.0.0.CR2/server/cts/conf/jboss-service.xml}
While LRUCachePolicy is coming from:
org.jboss.system.NoAnnotationURLClassLoader@c88440
Note that some other connectors are failing with the same error, but
these are silently gobbled up in some log.debug statement.
Carlo
On Thu, 2008-09-04 at 16:28 +0200, Carlo de Wolf wrote:
On Thu, 2008-09-04 at 15:39 +0200, Adrian Brock wrote:
> 15:15:34,302 WARN [StartStopLifecycleAction] Error during stop for
> org.jboss.ejb3.RemotingConnector
> java.lang.NoSuchFieldError: m_map
> at org.jboss.remoting.transport.socket.LRUPool.getContents(LRUPool.java:81)
> at
org.jboss.remoting.transport.socket.SocketServerInvoker.cleanup(SocketServerInvoker.java:437)
> at
org.jboss.remoting.transport.socket.SocketServerInvoker.stop(SocketServerInvoker.java:404)
> at org.jboss.remoting.transport.Connector.stop(Connector.java:1111)
At a glance LRUPool extends LRUCachePolicy which has a protected m_map
field. So for the moment I would say: Uh?
Carlo
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5:13 p.m.
I just did an update and retried e.g. smoke-tests-raw but the error doesn't show up
locally.
I can see it on hudson though:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
(goto bottom)
Adrian Brock wrote:
On Thu, 2008-09-04 at 17:14 +0300, Dimitris Andreadis wrote:
> I was seeing the same errors up until I cleaned up my workspace (I think thirdparty)
:-)
>
Hudson is showing the same errors, it does a clean checkout and build.
I always
rm -rf thirdpartry; svn update thirdparty
when somebody changes component-matrix anyway.
5:17 p.m.
New subject: LRUCachePolicy incompatiblity WAS Re: Remoting shutdown errors and warnings
On Thu, 2008-09-04 at 16:48 +0200, Adrian Brock wrote:
public java.util.Set getContents();
Code:
0: aload_0
1: getfield #12; //Field m_map:Ljava/util/HashMap;
4: invokevirtual #13; //Method
java/util/HashMap.keySet:()Ljava/util/Set;
7: areturn
I also don't think this method is very clever.
public Set getContents()
{
return m_map.keySet();
}
Since the m_map is an unsynchronized HashMap by default
this code can suffer from a number of problems:
1) It is not synchronized so you could cause
the LRUPool to hit a ConcurrentModificationException
when iterating over the map if you do Set.remove().
From the javadoc:
"The set supports element removal, which
removes the
corresponding mapping from this map"
2) Iterating over the set itself could have the
reverse CME problem for the caller if the pool modifies
the HashMap.
3) Sun's implementation of HashMap is known to
go into an infinite loop using 100% cpu
due to internal datastructure corruption when
you don't synchronize access properly.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5:39 p.m.
New subject: LRUCachePolicy incompatiblity WAS Re: Remoting shutdown errors and warnings
Great catch.
So it's this change that crept in jboss-common-core 2.2.8.GA by Ales, without even a
linked
JIRA issue:
To be honest, I wouldn't have thought that changing a protected field to a supertype
would
present compatibility issues.
I've made a jira for Ron, since we are expecting a remoting 2.2.4.SP2, anyway:
https://jira.jboss.org/jira/browse/JBREM-1032
Or the other option would be to rollback Ales' change, but then something else will
break.
Index:
X:/cvs/jboss-public/common/common-core/src/main/java/org/jboss/util/LRUCachePolicy.java
===================================================================
---
X:/cvs/jboss-public/common/common-core/src/main/java/org/jboss/util/LRUCachePolicy.java
(revision 2882)
+++
X:/cvs/jboss-public/common/common-core/src/main/java/org/jboss/util/LRUCachePolicy.java
(revision 2883)
@@ -22,6 +22,7 @@
package org.jboss.util;
import java.util.HashMap;
+import java.util.Map;
/**
* Implementation of a Least Recently Used cache policy.
@@ -39,7 +40,7 @@
/**
* The map holding the cached objects
*/
- protected HashMap m_map;
+ protected Map m_map;
/**
* The linked list used to implement the LRU algorithm
*/
@@ -79,6 +80,16 @@
m_maxCapacity = max;
}
+ /**
+ * Create map holding entries.
+ *
+ * @return the map
+ */
+ protected Map createMap()
+ {
+ return new HashMap();
+ }
+
// Public --------------------------------------------------------
// Service implementation ----------------------------------------------
@@ -90,7 +101,7 @@
*/
public void create()
{
- m_map = new HashMap();
+ m_map = createMap();
m_list = createList();
m_list.m_maxCapacity = m_maxCapacity;
m_list.m_minCapacity = m_minCapacity;
Adrian Brock wrote:
On Thu, 2008-09-04 at 16:28 +0200, Carlo de Wolf wrote:
> On Thu, 2008-09-04 at 15:39 +0200, Adrian Brock wrote:
>> 15:15:34,302 WARN [StartStopLifecycleAction] Error during stop for
>> org.jboss.ejb3.RemotingConnector
>> java.lang.NoSuchFieldError: m_map
>> at
org.jboss.remoting.transport.socket.LRUPool.getContents(LRUPool.java:81)
>> at
org.jboss.remoting.transport.socket.SocketServerInvoker.cleanup(SocketServerInvoker.java:437)
>> at
org.jboss.remoting.transport.socket.SocketServerInvoker.stop(SocketServerInvoker.java:404)
>> at org.jboss.remoting.transport.Connector.stop(Connector.java:1111)
> At a glance LRUPool extends LRUCachePolicy which has a protected m_map
> field. So for the moment I would say: Uh?
>
I've tried
rm -rf ~/.m2/repository/org/jboss/remoting/
rm -rf ~/.m2/repository/org/jboss/ejb3/
and did a clean build (including clobbering thirdparty).
Still seeing the error.
Disassembling LRUCachePolicy, I can see the
protected field m_map
$ javap -c -classpath jboss-common-core.jar
org.jboss.util.LRUCachePolicy
Compiled from "LRUCachePolicy.java"
public class org.jboss.util.LRUCachePolicy extends java.lang.Object
implements org.jboss.util.CachePolicy{
protected java.util.Map m_map;
Disassembing LRUPool, it is expecting a HashMap not a Map
so this has obviously changed at some point.
$ javap -c -classpath jboss-remoting.jar
org.jboss.remoting.transport.socket.LRUPool
Compiled from "LRUPool.java"
public class org.jboss.remoting.transport.socket.LRUPool extends
org.jboss.util.LRUCachePolicy{
...
public java.util.Set getContents();
Code:
0: aload_0
1: getfield #12; //Field m_map:Ljava/util/HashMap;
4: invokevirtual #13; //Method
java/util/HashMap.keySet:()Ljava/util/Set;
7: areturn
So JBoss Remoting needs recompiling over the latest
jboss-common-core
I don't know whether this fixes the other problems?
> Carlo
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
5:41 p.m.
New subject: LRUCachePolicy incompatiblity WAS Re: Remoting shutdown errors and warnings
On Thu, 2008-09-04 at 18:39 +0300, Dimitris Andreadis wrote:
To be honest, I wouldn't have thought that changing a protected
field to a supertype would
present compatibility issues.
The field's type is part of the resolution process,
its an exact match.
http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.htm...
If it wasn't, code like
private HashMap m_map;
m_map.clone()
(not a method on Map) would break in just as strange ways.
But I think the JVM could give more information to determine the cause,
i.e. if it can't find the expected field it could do a search of all
the fields and produce:
java.lang.NoSuchFieldError: m_map - incompatible type change -
compilation had java.util.HashMap, it is now java.util.Map
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11:13 p.m.
/When the Shire falls under the fiery gaze of the Dark Lord ... it can't
be good. / O:-)
JBossRemoting 2.5.0.GA is now tagged, and the problem is gone.
[The sudden increase in release number shouldn't affect any JBoss
software. It just reflects the fact that I upgraded all the jars used
by the Remoting test suite, which led to dropping Apache Tomcat, which
means Remoting 2.x no longer completely supports jdk 1.4. It's really
just 2.4.0.SP2.]
-Ron
Adrian Brock wrote:
This has been around for over a week without anybody fixing it,
so I guess whoever is responsible doesn't know about it?
The errors are logged when you shutdown the server
so it isn't validated by the testsuite.
15:15:34,249 ERROR [Connector] invalid Object Name
javax.management.InstanceNotFoundException:
jboss.remoting:service=invoker,transport=bisocket,host=127.0.0.1,port=4457,JBM_clientMaxPoolSize=200,clientLeasePeriod=10000,clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper,dataType=jms,marshaller=org.jboss.jms.wireformat.JMSWireFormat,numberOfCallRetries=1,numberOfRetries=10,pingFrequency=214748364,pingWindowFactor=10,socket.check_connection=false,stopLeaseOnFailure=true,timeout=0,unmarshaller=org.jboss.jms.wireformat.JMSWireFormat
is not registered.
at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
at
org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
at
org.jboss.remoting.util.SecurityUtility.unregisterMBean(SecurityUtility.java:538)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1103)
at
org.jboss.remoting.transport.Connector.destroy(Connector.java:1167)
15:15:34,302 WARN [StartStopLifecycleAction] Error during stop for
org.jboss.ejb3.RemotingConnector
java.lang.NoSuchFieldError: m_map
at
org.jboss.remoting.transport.socket.LRUPool.getContents(LRUPool.java:81)
at
org.jboss.remoting.transport.socket.SocketServerInvoker.cleanup(SocketServerInvoker.java:437)
at
org.jboss.remoting.transport.socket.SocketServerInvoker.stop(SocketServerInvoker.java:404)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1111)
15:15:38,353 ERROR [Connector] invalid Object Name
javax.management.InstanceNotFoundException:
jboss.remoting:service=invoker,transport=socket,host=127.0.0.1,port=4446,dataType=invocation,enableTcpNoDelay=true,marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller,unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller
is not registered.
at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
at
org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
at
org.jboss.remoting.util.SecurityUtility.unregisterMBean(SecurityUtility.java:538)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1103)
at
org.jboss.remoting.transport.Connector.destroy(Connector.java:1167)
5708
days inactive
5713
days old
jboss-development@lists.jboss.org
10 comments
4 participants
participants (4)
-
Adrian Brock -
Carlo de Wolf -
Dimitris Andreadis -
Ron Sigal