MINA
  1. MINA
  2. DIRMINA-889

MINA is lacking a set of exceptions to properly inform the user about what is going on

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0.0-M1
    • Component/s: None
    • Labels:
      None

      Description

      following scenario:

      A MINA powered server application is reading data from network, which is sent by any client. While server is getting data, the connection get's broken. The read() from server is interrupted and exceptionCaught() in IoHandler is called.

      Currently, my exceptionCaught() implementation looks like this:


      @Override
      public void exceptionCaught(IoSession session, Throwable throwable) throws Exception {
      logger.error("exception Caught. session={}. Exception:\n {}", new Object[]

      {Utils.longToHexString(session.getId()), Utils.getStackTraceAsString(throwable)}

      );
      logger.debug("Closing the session now! session={}", Utils.longToHexString(session.getId()));
      session.close(true);
      }


      Problem is, that I don't know how to differentiate between "real and important exceptions", which need to be logged more prominent and exception which might occur because of a client has been disconnected correctly (broken network connection). if a connection get's broken, I just get a generic IOException:


      Feb 21, 2012 5:10:20 PM de.root1.simon.Dispatcher exceptionCaught
      Schwerwiegend: exception Caught. session=0x00000002. Exception:
      java.io.IOException: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
      at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
      at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
      at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:218)
      at sun.nio.ch.IOUtil.read(IOUtil.java:191)
      at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359)
      at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:280)
      at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:44)
      at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:695)
      at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:668)
      at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:657)
      at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)
      at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1141)
      at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
      at java.lang.Thread.run(Thread.java:722)


      There should be some MINA exceptions handling (f.i. in this special scenario a kihd of "UnexpectedlyClosedConnectionException" or so) this kind of problems, so that one can differentiate the exceptions in "exceptionCaught" to know what really happened somewhere deep in MINA.
      Alternatively, there could be some error-codes. But would really prefer the solution with the MINA exceptions ...

        Activity

        Alex C. created issue -
        Julien Vermillard made changes -
        Field Original Value New Value
        Fix Version/s 3.0.0-M1 [ 12313531 ]
        Hide
        Julien Vermillard added a comment -

        I created a new set of Exception for MINA 3 whcih (I hope) are more explicit. and the default IoHandler behaviour is to clsoe the connection if an exception is raised (fail-fast).

        Feel free to reopen or send a mail if you have any comments

        Show
        Julien Vermillard added a comment - I created a new set of Exception for MINA 3 whcih (I hope) are more explicit. and the default IoHandler behaviour is to clsoe the connection if an exception is raised (fail-fast). Feel free to reopen or send a mail if you have any comments
        Julien Vermillard made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Julien Vermillard [ vrm ]
        Resolution Fixed [ 1 ]
        Hide
        Alex C. added a comment -

        Julien,

        could you please point me to the commit diff?

        thx,
        Alex

        Show
        Alex C. added a comment - Julien, could you please point me to the commit diff? thx, Alex
        Hide
        Julien Vermillard added a comment -

        Basicly IOException are encapsulated in MinaException (severe erorrs you can't recover.
        https://git-wip-us.apache.org/repos/asf?p=mina.git;a=commit;h=7b9e82d2532cf4e58c922c04b710f4848eed5b1a
        https://git-wip-us.apache.org/repos/asf?p=mina.git;a=commit;h=92a7bca47fddaf8c48a840e4a9f0ca00f6336281

        And protocol execption are thrown as ProtocolDecode or Encode execption, wich mean bad usage of the protocol (badly encoded messages)

        Show
        Julien Vermillard added a comment - Basicly IOException are encapsulated in MinaException (severe erorrs you can't recover. https://git-wip-us.apache.org/repos/asf?p=mina.git;a=commit;h=7b9e82d2532cf4e58c922c04b710f4848eed5b1a https://git-wip-us.apache.org/repos/asf?p=mina.git;a=commit;h=92a7bca47fddaf8c48a840e4a9f0ca00f6336281 And protocol execption are thrown as ProtocolDecode or Encode execption, wich mean bad usage of the protocol (badly encoded messages)

          People

          • Assignee:
            Julien Vermillard
            Reporter:
            Alex C.
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development