[jboss-jira] [JBoss JIRA] (AS7-3828) EJB client tries to invoke EJBs after application was undeployed

jaikiran pai (JIRA) jira-events at lists.jboss.org
Wed Feb 29 09:50:36 EST 2012


    [ https://issues.jboss.org/browse/AS7-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672144#comment-12672144 ] 

jaikiran pai commented on AS7-3828:
-----------------------------------

{quote}
clients are started, servers are warmed up for 1 minute

    first server is failed using one of the failure types
    server is remained failed for 1 minute
{quote}
So in the undeploy case, the deployment is undeployed from server 1 (and stays thus for a minute). Do *all* subsequent invocations on that deployment, from a client fail during that 1 minute window or do only a few initial requests fail and the rest failover to a different node?

There's going to be a time window when the app undeploys on server 1 and the client receives a undeploy notification. During that window if the client invokes on the bean, the EJB client API would still consider a node as eligible since it hasn't yet received the undeploy notification. As soon as the undeploy notification is received, the failover to a different node is going to happen for subsequent invocations. Typically, this undeployed notification to client is received within a few seconds (on my local system using within a second).

                
> EJB client tries to invoke EJBs after application was undeployed
> ----------------------------------------------------------------
>
>                 Key: AS7-3828
>                 URL: https://issues.jboss.org/browse/AS7-3828
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: 7.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: jaikiran pai
>            Priority: Critical
>              Labels: eap6_LA, failover_testing
>             Fix For: 7.1.1.Final
>
>
> And this results in NoSuchEJBException.
> One more feature that was fully supported in previous version (AS 5.1).
> {noformat}
> 2012/02/20 10:59:11:336 EST [WARN ][Runner - 43] SFCORE_LOG - Error sampling data:  <org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not get valid response. Runner: 43.>
>         org.jboss.smartfrog.loaddriver.RequestProcessingException: Could not get valid response. Runner: 43.
> 	at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:79)
> 	at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> 	at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> 	at java.lang.Thread.run(Thread.java:662)
> Caused by: javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatefulSBImpl]
> 	at org.jboss.ejb.client.remoting.GeneralInvocationFailureResponseHandler.processMessage(GeneralInvocationFailureResponseHandler.java:75)
> 	at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:385)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:371)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	... 1 more
> {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

        


More information about the jboss-jira mailing list