[EJB 3.0] - Resource Injection into Servlet Filter = Receive timed out
by ctf
JBoss AS 5.0
JDK 6.x
Window XP
Eclipse
JBoss Plugin
My Eclipse project is set up using the default EJB project structure (Ear project, EJB project, Web project). I'm trying to inject a stateless ejb into a servlet filter, but upon deployment, I get the following exception....
00:11:22,593 ERROR [[/acme]] Exception starting filter MyServletFilter
| java.lang.RuntimeException: Unable to inject jndi dependency: env/com.acme.myApp.servlets.MyServletFilter/myStatelessEJB into property com.acme.myApp.servlets.MyServletFilter.myStatelessEJB: Receive timed out
| at org.jboss.injection.JndiPropertyInjector.lookup(JndiPropertyInjector.java:82)
| at org.jboss.injection.JndiPropertyInjector.inject(JndiPropertyInjector.java:99)
| at org.jboss.web.tomcat.service.TomcatInjectionContainer.processInjectors(TomcatInjectionContainer.java:360)
| at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:243)
| at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:220)
| at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:332)
| at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:90)
| at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3783)
| at org.apache.catalina.core.StandardContext.start(StandardContext.java:4413)
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:367)
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:146)
| at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:460)
| at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
| at org.jboss.web.deployers.WebModule.start(WebModule.java:96)
| 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 org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| 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:668)
| at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
| at $Proxy36.start(Unknown Source)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
| at org.jboss.system.ServiceController.start(ServiceController.java:460)
| at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:146)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:104)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
| at org.jboss.Main.boot(Main.java:209)
| at org.jboss.Main$1.run(Main.java:547)
| at java.lang.Thread.run(Unknown Source)
| Caused by: javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out]]
| at org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1339)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:804)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:673)
| at org.jboss.ejb3.JndiUtil.lookup(JndiUtil.java:44)
| at org.jboss.injection.JndiPropertyInjector.lookup(JndiPropertyInjector.java:75)
| ... 65 more
| Caused by: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out]
| at org.jnp.interfaces.NamingContext.discoverServer(NamingContext.java:1119)
| at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1227)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:516)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:509)
| at javax.naming.InitialContext.lookup(Unknown Source)
| at org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1333)
| ... 69 more
| Caused by: java.net.SocketTimeoutException: Receive timed out
| at java.net.PlainDatagramSocketImpl.receive0(Native Method)
| at java.net.PlainDatagramSocketImpl.receive(Unknown Source)
| at java.net.DatagramSocket.receive(Unknown Source)
| at org.jnp.interfaces.NamingContext.discoverServer(NamingContext.java:1089)
| ... 74 more
>From what I can tell, what I'm doing is pretty basic and 'by the book'. In the EJB project, I have an interface with @Local and an implementation with @Stateless. The servlet filter declares a private variable as the interface/local type along with the @EJB attribute. Everything I read shows that this is the extent of the configuration I should expect. So I don't know what to tweak or try.
Any ideas?
Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199308#4199308
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199308
17 years, 3 months
[Installation, Configuration & DEPLOYMENT] - JBoss 5.0 Taking LONG Time to Start Up
by ctf
Hi,
I'm just starting to check out 5.0. I have pretty much a basic/default installation of JBoss AS 5.0. The same EJB app that takes about a minute to start up in 4.x takes more than 4 minutes in 5.0. Some sample output...
| 22:41:14,203 INFO [WebService] Using RMI server codebase: http://localhost:8083/
| 22:41:34,515 INFO [NativeServerConfig] JBoss Web Services - Stack Native Core
| 22:41:34,515 INFO [NativeServerConfig] 3.0.4.SP1
| [..... LONG WAIT HERE .....]
| 22:43:44,359 INFO [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext@7764591{vfsfile:/C:/jboss-5.0.0.GA/server/default/deploy/myApp.ear/myAppEJB.jar/}
| 22:43:44,359 INFO [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext@7764591{vfsfile:/C:/jboss-5.0.0.GA/server/default/deploy/myApp.ear/myAppEJB.jar/}
|
As you can see, right after "[NativeServerConfig] 3.0.4.SP1", you can see that about 2 minutes elapse before the next line. I'm using Eclipse + JBoss plugin (Windows XP, JDK 6.x) to deploy and start up JBoss.
Is this normal? Any suggestions on how to speed this up? I don't need web services, so if that's the culprit, any tips on removing/disabling it?
Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199307#4199307
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199307
17 years, 3 months
[Remoting] - Re: JBREM-877: New Socket Connection is being Created for Ev
by ron.sigal＠jboss.com
Hi Vinay,
I'm looking at your thread dumps, and I don't see anything strange from the perspective of Remoting. I see a bunch of Remoting ServerThreads in a WAITING state, which implies they're currently not in use.
The only exception I've noticed is in the server-stack.log file you sent me:
| "WorkerThread#21[150.158.73.73:4114]" prio=6 tid=0x2b6c2c00 nid=0x570 in Object.wait() [0x2eaff000..0x2eaffa14]
| java.lang.Thread.State: TIMED_WAITING (on object monitor)
| at java.lang.Object.wait(Native Method)
| - waiting on <0x09289300> (a java.lang.Integer)
| at com.barco.cms.openapi.PerspectiveMgtAPIImpl.getEvents(Unknown Source)
| - locked <0x09289300> (a java.lang.Integer)
| at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
| at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
| at com.barco.cms.openapi.PerspectiveMgtAPIImpl.initialSteps(Unknown Source)
| at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:146)
| at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
| at org.jboss.aspects.tx.TxInterceptor$Never.invoke(TxInterceptor.java:66)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
| at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
| at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
| at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
| at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
| - locked <0x09a34058> (a org.jboss.remoting.transport.socket.ServerThread)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
|
which seems to be related to your application code. Could that be where you're experiencing a hang up?
Also, server-stack.log just has 355 threads. That doesn't sound like enough for you to run out of threads.
I'm not getting the picture yet.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199305#4199305
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199305
17 years, 3 months
[JBoss Cache: Core Edition] - Cache service not registered on cold start EAR persistent un
by ryanrlamothe
I have been working to enable Hibernate second-level entity caching for use with our detached entities.
Server: JBossAS 4.2.2
Cache: 1.4.1 (included version in JBossAS 4.2.2)
The behavior that I am seeing is that if I cold start the container with no EAR deployed, everything starts fine, including the cache. Then I deploy the EAR and the persistence unit deploys fine and finds the cache service MBean.
Now, if deploy the EAR and cold start the container the persistence unit fails to load because it cannot find the cache service. The exception is as follows:
javax.persistence.PersistenceException: org.hibernate.cache.CacheException: java.lang.RuntimeException: Error creating MBeanProxy: jboss.cache:service=EJB3EntityCache
Hot deploy the EAR and the persistence unit will be found.
How do I configure either JBoss or my EAR/persistence to depend on the cache being completed deployed before the EAR?
If you need me to post any files, please let me know. Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199304#4199304
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199304
17 years, 3 months
[Remoting] - Re: Socket Invoker timeout
by mohitanchlia
anonymous wrote : The call to java.net.Socket.connect(SocketAddress endpoint), which is the overloaded version of connect() used in org.jboss.remoting.transport.socket.MicroSocketClientInvoker, does not time out.
I didn't understand the above "does not timeout". With what you described then I shouldn't be seeing this:
2008-12-31 17:20:14,297 DEBUG [transport.socket.MicroSocketClientInvoker:ajp-0.0.0.0-8009-99] - SocketClientInvoker[18b118, socket://10.10.8.77:3873] got Exception java.net.NoRouteToHostException: No route to host, creation attempt took 5001 ms
--
5001 ms corresponds to 5 sec timeout set by me. Why would MicroSocketClientInvoker timeout when 5 sec timeout is really set for "read" requests made by client invoker to server invoker?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199301#4199301
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199301
17 years, 3 months