Uploaded image for project: 'EJB Client Library (AS7+)'
  1. EJB Client Library (AS7+)
  2. EJBCLIENT-130

Channel exception should not occur during fail-over triggered by NoSuchEJBException

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 2.0.1.Final, 2.1.0.Final
    • Fix Version/s: 2.1.0.Final
    • Labels:
      None

      Description

      The following channel exception arises in the context of an EJBClient making invocations on a node which is in the process of shutting down:

      EJBInvocationHandler: exception in doInvoke: Channel Channel ID 8232151c (outbound) of Remoting connection 2e0b410a to /127.0.0.1:8080 has been closed
      java.io.IOException: Channel Channel ID 8232151c (outbound) of Remoting connection 2e0b410a to /127.0.0.1:8080 has been closed
      	at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:123)
      	at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:115)
      	at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
      	at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
      	at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
      	at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
      	at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:531)
      	at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
      	at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423)
      	at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:114)
      	at org.jboss.remoting3.remote.RemoteReadListener$1$1.run(RemoteReadListener.java:56)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      	at java.lang.Thread.run(Thread.java:744)
      IncrementTask: caught exception: java.io.IOException: Channel Channel ID 8232151c (outbound) of Remoting connection 2e0b410a to /127.0.0.1:8080 has been closed
      javax.ejb.EJBException: java.io.IOException: Channel Channel ID 8232151c (outbound) of Remoting connection 2e0b410a to /127.0.0.1:8080 has been closed
      	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:244)
      	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
      	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
      	at com.sun.proxy.$Proxy23.increment(Unknown Source)
      	at org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase$IncrementTask.run(RemoteFailoverTestCase.java:400)
      	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
      	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
      	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
      	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      	at java.lang.Thread.run(Thread.java:744)
      Caused by: java.io.IOException: Channel Channel ID 8232151c (outbound) of Remoting connection 2e0b410a to /127.0.0.1:8080 has been closed
      	at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:123)
      	at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:115)
      	at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
      	at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
      	at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
      	at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
      	at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:531)
      	at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
      	at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423)
      	at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:114)
      	at org.jboss.remoting3.remote.RemoteReadListener$1$1.run(RemoteReadListener.java:56)
      	... 3 more
      

      When we make an invocation, we start out with an EJBClientInvocationContext representing the invocation client and the invocation parameters. We then choose an EJBReceiver which can handle the invocation and create an EJBReceiverInvocationContext to represent it. The EJBReceiverInvocationContext refers to the EJBReceiver and also Channel used. When we successfully send out an invocation on a channel, we store the fact that we need to wait for a response in a map (ChannelAssociation.waitingMethodInvocations) specifying the invocationId and the EJBReceiverInvocationContext.

      If the response returns with a NoSuchEJBException, as it may if the EJB deployment is already refusing to service invocations by way of its shutdown interceptor, we retry the invocation, ultimately using a new EJBReceiverInvocationContext (and so a new Channel).

      What is causing the exception is that, before retrying, we are not removing the invocationid and the old EJBReceiverInvocationContext from the map of waiting invocations. Consequently, when the Channel is closed as a result of the server shutting down, it triggers the exception above, despite the fact that a new EJBReceiver was chosen and the retry of the invocation does fail over correctly.

      This problem affects scenarios involving undeployment as well as shutdown.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  rachmato Richard Achmatowicz
                  Reporter:
                  rachmato Richard Achmatowicz
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: