[EJB/JBoss] - Configuration JBoss 5.0.0.Beta4: java.rmi.MarshalException:
by davidnez
I'm migrating an application from ejb to ejb3.
I'm using Swing, Hibernate, EJB3, JNDI and JBOSS-5.0.0.Beta4.
When I load a client done with Swing launghing JavaWebStart, the application loads by jndi the ejb's correctly.
contextService = (ContextService) context.lookup("gn_j2ee_application/ContextServiceBean/remote");
But when I call any method on the swing client from de ejb, it fails.
The method that is calling is getEnvironment, and the motive of the error feels something like Caused by: java.io.NotSerializableException: org.jboss.security.auth.callback.SecurityAssociationHandler. But I don't know why and what I have to modify.
Does anyone could help me?
The error that return is:
java.lang.reflect.UndeclaredThrowableException
at $Proxy1.getEnvironment(Unknown Source)
at com.quavantis.gui.secenet.ApplicationMain.showLogin(ApplicationMain.java:448)
at com.quavantis.gui.secenet.ApplicationMain.main(ApplicationMain.java:419)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is:
java.io.NotSerializableException: org.jboss.security.auth.callback.SecurityAssociationHandler
at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:122)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:669)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:108)
... 12 more
Caused by: java.io.NotSerializableException: org.jboss.security.auth.callback.SecurityAssociationHandler
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at org.jboss.aop.util.MarshalledValue.(MarshalledValue.java:73)
at org.jboss.aop.metadata.SimpleMetaData.writeExternal(SimpleMetaData.java:322)
at java.io.ObjectOutputStream.writeExternalData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at org.jboss.aop.joinpoint.MethodInvocation.writeExternal(MethodInvocation.java:356)
at java.io.ObjectOutputStream.writeExternalData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:120)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:95)
at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:943)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:586)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:108)
at $Proxy1.getEnvironment(Unknown Source)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160478#4160478
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160478
17 years, 9 months
[JBoss Cache: Core Edition] - Re: How memory consumption behave?
by manik.surtani＠jboss.com
"jorgemoralespou_2" wrote : Hi,
| My questions are:
| 1- Why recent loaded apps have such a difference in memory?
|
Is this running within a JMX environment, either JBoss AS' JmxConsole or Java 5's jconsole? If so, I'd recommend comparing the number of nodes in each cache rather than the memory used, to make sure these match up.
"jorgemoralespou_2" wrote :
| 2- Why memory fills so much during state transfer?
|
Short-lived transient objects. State is transferred by creating NodeData objects, and streaming these. These are then unmarshalled on the recipient, data retrieved, real nodes created, and the NodeData objects left for gc to clear up.
"jorgemoralespou_2" wrote :
| Another thing we have seen is that we have a region with a default cache loader of 24 hours, but we have in this region data only valid for a day, until 24:00 PM, so we have a scheduler job, that removes such a node, doing a cache.remove(FQN). When we run this job, memory lowers, but after 24 hours from start it lowers much more, so we think eviction policy is happening of internal cache data for the removed nodes. Can this be possible?
|
Again this could be a gc thing. If you do a remove() on the region root so that everything in that region is removed, the node is removed from it's parent's children map such that the node is no longer accessible. So the node - and all it's children and children's children - are still around until gc clears it all away. I'm guessing this is what you are seeing. Again, if you have jconsole enabled, you can watch gc cycles and I'm guessing these drops in memory usage will correspond with gc kicking in.
We have set log levels to TRACE, but we have to wait another 24 hours to see this behaviour.
Thanks,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160473#4160473
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160473
17 years, 9 months
[JNDI/Naming/Network] - Re: How to Access EJB over HTTP in remote machine?
by ritesh163
"robert.geisler" wrote :
| just for the InvokerURLs of the servlets you have to set the external ip, because JBoss sends the InvokerURL back to the clients to let them know where to connect to.
| robert
I had configured both standardjboss.xml and jboss.xml. I had started client Jboss with command as : run.sh -c default -b [internal ip] and set InvokerURLs of the servlets to the external ip. But following error occures:
| 21:05:55,944 INFO [Server] Server Name: default
| 21:05:55,944 INFO [Server] Server Home Dir: /home/remit/jboss-4.0.4.GA/server/default
| 21:05:55,944 INFO [Server] Server Home URL: file:/home/remit/jboss-4.0.4.GA/server/default/
| 21:05:55,944 INFO [Server] Server Log Dir: /home/remit/jboss-4.0.4.GA/server/default/log
| 21:05:55,945 INFO [Server] Server Temp Dir: /home/remit/jboss-4.0.4.GA/server/default/tmp
| 21:05:55,946 INFO [Server] Root Deployment Filename: jboss-service.xml
| 21:05:56,505 INFO [ServerInfo] Java version: 1.5.0_08,Sun Microsystems Inc.
| 21:05:56,505 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_08-b03,Sun Microsystems Inc.
| 21:05:56,505 INFO [ServerInfo] OS-System: Linux 2.6.18-8.el5,i386
| 21:05:57,399 INFO [Server] Core system initialized
| 21:06:02,350 INFO [ServiceConfigurator] Problem configuring service jboss:service=Naming
| org.jboss.deployment.DeploymentException: No Attribute found with name: RmiBindAddress
| at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:318)
| at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:460)
| at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
| at org.jboss.system.ServiceController.install(ServiceController.java:226)
| 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: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 $Proxy4.install(Unknown Source)
| at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
| at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
| 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: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.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| 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 $Proxy5.deploy(Unknown Source)
| at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
| at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
| at org.jboss.Main.boot(Main.java:200)
| at org.jboss.Main$1.run(Main.java:464)
| at java.lang.Thread.run(Thread.java:595)
|
Here, I am talking about client side Jboss (machine B). machine A is already in External IP, so it runs on external IP. Will machine A also require invoker? I didn't configure invoker in machine A because it invoke other ejb which is in machine B. Machine B has internal ip and jboss also run on that ip which is redirected by router ip or external ip.
I am hoping to receive reply ....
thank you.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160471#4160471
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160471
17 years, 9 months
[JBoss Cache: Core Edition] - How memory consumption behave?
by jorgemoralespou_2
Hi,
We have a 2 node clustered application, with JBC 1.4.1-SP9. When we upgrade our app, we see this behaviour:
1- We stop node 1, upgrade our app, and start node 1. (Node 2 keeps processing application traffic)
2- It takes a while to start (~5 minutes) , since we have fetchInMemoryState to true.
3- The server ends starting, and initially it has around 1GB old space memory used.
4- 15 minutes later we do the same thing with node 2. We stop it, update it, and start it. It takes some time (~4 minutes), and finally loads with 1.4Gb.
While this state transfer from node 1 to node 2 is happening, node 1 memory gets up to 1.9Gb.
5- After a while, there is a Full GC, and memory lowers to 1.4 Gb in node1, and 1 Gb in node 2.
My questions are:
1- Why recent loaded apps have such a difference in memory?
2- Why memory fills so much during state transfer?
Another thing we have seen is that we have a region with a default cache loader of 24 hours, but we have in this region data only valid for a day, until 24:00 PM, so we have a scheduler job, that removes such a node, doing a cache.remove(FQN). When we run this job, memory lowers, but after 24 hours from start it lowers much more, so we think eviction policy is happening of internal cache data for the removed nodes. Can this be possible?
We have set log levels to TRACE, but we have to wait another 24 hours to see this behaviour.
Thanks,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160463#4160463
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160463
17 years, 9 months