[Design of the JBoss EJB Container] - JBoss 4.0.X SVN won't start with Cluster
by clebert.suconic＠jboss.com
I just downloaded JBoss 4.0 from SVN, and I'm getting this error when I start my application:
anonymous wrote : [org.jboss.ejb.plugins.local.BaseLocalProxyFactory] Bound EJB LocalHome 'CustomerInventoryEnt' to jndi 'local/CustomerInventoryEnt'
| 2006-07-31 15:38:03,167 WARN [org.jboss.system.ServiceController] Problem starting service jboss.j2ee:jndiName=CorpAuditSes,service=EJB
| javax.naming.CommunicationException [Root exception is java.io.NotSerializableException: org.jboss.ha.framework.interfaces.FamilyClusterInfoImpl]
| at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:522)
| at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:477)
| at javax.naming.InitialContext.rebind(InitialContext.java:367)
| at org.jboss.util.naming.Util.rebind(Util.java:126)
| at org.jboss.util.naming.Util.rebind(Util.java:113)
| at org.jboss.proxy.ejb.ProxyFactoryHA.setupInvokers(ProxyFactoryHA.java:126)
| at org.jboss.proxy.ejb.ProxyFactory.start(ProxyFactory.java:242)
| at org.jboss.proxy.ejb.ProxyFactoryHA.start(ProxyFactoryHA.java:87)
| at org.jboss.ejb.SessionContainer.startInvokers(SessionContainer.java:440)
| at org.jboss.ejb.SessionContainer.startService(SessionContainer.java:399)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.ServiceController.start(ServiceController.java:417)
| at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy41.start(Unknown Source)
| at org.jboss.ejb.EjbModule.startService(EjbModule.java:420)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.ServiceController.start(ServiceController.java:417)
| at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy17.start(Unknown Source)
| at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:662)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
|
And FamilyClusterInfoImpl is not serializable indeed.
Any thoughts?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962016#3962016
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962016
18 years, 5 months
[Design of JBoss Profiler] - Problems Jboss 4.0.2/JKD1.4.2/Profiler1.0.RC3/Solaris 9
by thof
I use Jboss Profiler 1.0 RC3 with
-JBoss 4.0.2,
-JD1.4.2
-Solaris 9
JVM for Jboss is running with -server. On 8 of 10 tries to capture data (e.g. kill -3) JVM crashes with a core dump. Here is the console output
Full thread dump Java HotSpot(TM) Server VM (1.4.2_05-b04 mixed mode):
"UIL2(SocketManager.MsgPool@1bfdaa4 client=172.16.10.151:2900)#2" daemon prio=5
tid=0x02416d10 nid=0x5a in Object.wait() [717ff000..717ffc28]
at java.lang.Object.wait(Native Method)
- waiting on <0x7b40c470> (a
....
"VM Thread" prio=5 tid=0x000fc588 nid=0x2 runnable
"VM Periodic Task Thread" prio=10 tid=0x00109bc0 nid=0xa waiting on condition
"Suspend Checker Thread" prio=10 tid=0x00104cb0 nid=0x5 runnable
JBossProfiler: Initializing DataGathering
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0xFF3E6554
Function=memcpy+0x78
Library=/usr/platform/sun4u/lib/libc_psr.so.1
Current Java thread:
at java.lang.Object.wait(Native Method)
- waiting on <0x9aa860f8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
- locked <0x9aa860f8> (a java.lang.ref.ReferenceQueue$Lock)
at org.jboss.mq.server.MessageCache.run(MessageCache.java:232)
at java.lang.Thread.run(Thread.java:534)
Dynamic libraries:
0x10000 /usr/j2sdk1.4.2_05/bin/java
0xff370000 /usr/lib/libthread.so.1
0xff3fa000 /usr/lib/libdl.so.1
0xff280000 /usr/lib/libc.so.1
0xff3e6000 /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1
0xfec00000 /usr/j2sdk1.4.2_05/jre/lib/sparc/server/libjvm.so
0xff230000 /usr/lib/libCrun.so.1
0xff210000 /usr/lib/libsocket.so.1
0xfeb00000 /usr/lib/libnsl.so.1
0xfebd0000 /usr/lib/libm.so.1
0xff1f0000 /usr/lib/libsched.so.1
0xfeae0000 /usr/lib/libmp.so.2
0xfeac0000 /usr/lib/librt.so.1
0xfeaa0000 /usr/lib/libaio.so.1
0xfea80000 /usr/lib/libmd5.so.1
0xfea60000 /usr/platform/SUNW,Ultra-Enterprise/lib/libmd5_psr.so.1
0xfea10000 /usr/j2sdk1.4.2_05/jre/lib/sparc/native_threads/libhpi.so
0xfe9d0000 /usr/j2sdk1.4.2_05/jre/lib/sparc/libverify.so
0xfe990000 /usr/j2sdk1.4.2_05/jre/lib/sparc/libjava.so
0xfe970000 /usr/j2sdk1.4.2_05/jre/lib/sparc/libzip.so
0xfe8a0000 /usr/lib/locale/iso_8859_1/iso_8859_1.so.2
0xfe840000 /usr/local/jboss-profiler-1.0/jvmpi/solaris/libjbossInspector.so
0xf9700000 /usr/local/lib/libstdc++.so.6
0xfe820000 /usr/local/lib/libgcc_s.so.1
0xfbbd0000 /usr/j2sdk1.4.2_05/jre/lib/sparc/libnet.so
0x77060000 /usr/j2sdk1.4.2_05/jre/lib/sparc/libnio.so
0x77040000 /usr/lib/libsendfile.so.1
0x75d10000 /usr/j2sdk1.4.2_05/jre/lib/sparc/libioser12.so
0x754a0000 /usr/j2sdk1.4.2_05/jre/lib/sparc/librmi.so
Heap at VM Abort:
Heap
def new generation total 169856K, used 169856K [0x79400000, 0x83ee0000, 0x994
00000)
eden space 164736K, 100% used [0x79400000, 0x834e0000, 0x834e0000)
from space 5120K, 100% used [0x834e0000, 0x839e0000, 0x839e0000)
to space 5120K, 0% used [0x839e0000, 0x839e0000, 0x83ee0000)
tenured generation total 349568K, used 65649K [0x99400000, 0xae960000, 0xd940
0000)
the space 349568K, 18% used [0x99400000, 0x9d41c458, 0x9d41c600, 0xae960000)
compacting perm gen total 28928K, used 28784K [0xd9400000, 0xdb040000, 0xf9400
000)
the space 28928K, 99% used [0xd9400000, 0xdb01c3d8, 0xdb01c400, 0xdb040000)
Local Time = Mon Jul 31 16:25:14 2006
Elapsed Time = 630
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2_05-b04 mixed mode)
#
****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = hs_err_pid3352.log
ContendedEnter ThreadId -1723858328 268
# An error report file has been saved as hs_err_pid3352.log.
# Please refer to the file for further information.
#
PC = 0xff3e6554
SIGNAL = 11
FUNCTION NAME = memcpy
OFFSET = 0x78
LIBRARY NAME = /usr/platform/sun4u/lib/libc_psr.so.1
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.
Segmentation Fault - core dumped
Any ideas?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961889#3961889
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961889
18 years, 5 months
[Design of JBoss Collaboration Server] - Re: Feature Request - I'll do the work!
by sappenin
I agree that the "username/password" in a config file is intrusive and non-elegant.
I like the idea of disabling the invokers. The only downside is that a system may indeed WANT to have a separate machine publish to a remote queue on the JBCS machine. Disabling the invoker would prevent this. Even so, one may make the argument that if there's going to be 2 servers communicating stuff between them (like, "send this message"), then a web-services interface might be a better service interface than a remote, password-protected queue.
Just in case, though (directed at AronSogor), how would the "JAAS semi-simple" solution work? I was thinking yesterday about the way EJB's have a "runas" annotation, directing the bean to "Run As" a given user role. Is there a way to get MBeans to do something like this, since (for example) the JMSMaillistener is the one submitting to the mail queue.
If the JMS is protected by JAAS (in your semi-simple solution), then what is the mechanism for becoming the role that you want to use when publishing to the queue?
Thanks!
David
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961880#3961880
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961880
18 years, 5 months