[
https://issues.apache.org/jira/browse/DIRMINA-1140?focusedWorklogId=1045331&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1045331
]
ASF GitHub Bot logged work on DIRMINA-1140:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 02/Oct/26 07:17
Start Date: 02/Oct/26 07:17
Worklog Time Spent: 10m
Work Description: the-thing opened a new pull request, #75:
URL: https://github.com/apache/mina/pull/75
Fix for DIRMINA-1140
I was able to retrofit JIRA's attached minimal working example into a test
case. The title is slightly wrong as this can happen for a single acceptor that
is being disposed.
`org.apache.mina.core.service.AbstractIoService#dispose(boolean)` is the
root cause. When a null `java.util.concurrent.Executor` is passed in
`org.apache.mina.core.service.AbstractIoService#AbstractIoService` creates a
new `java.util.concurrent.Executors#newCachedThreadPool()` and the service is
responsible for shutting it down during disposal.
When `java.util.concurrent.ExecutorService` is shut down it usually
interrupts threads which leads to
https://github.com/apache/mina/blob/b6739d21e63f5541dcaecaff1b3b57993feeb9e3/mina-core/src/main/java/org/apache/mina/transport/socket/nio/NioDatagramAcceptor.java#L169
interrupted exception being thrown here.
Suggested fix is to check the flag if service is being disposed when
`java.lang.InterruptedException` exception is caught and do not rethrow it. I
checked and this doesn't happen for
`org.apache.mina.transport.socket.nio.NioSocketAcceptor` etc.
Aleternative fixes:
- use `java.util.concurrent.Semaphore#acquireUninterruptibly()` instead of
`java.util.concurrent.Semaphore#acquire()`, but since the thread was
interrupted we probably want it to be responsive and do not attempt to acquire
the lock (haven't tested this solution).
- completely ignore - catch without logging / throwing
`InterruptedException`. Not the best since if the custom Executor is passed to
`NioDatagramAcceptor` and is shutdown before the unbind happened, it will lead
to similar error, but in this case we actually want to throw it for the user to
know about bad shutdown order (demo in
`org.apache.mina.transport.socket.nio.NioDatagramAcceptorTest#shouldThrowExceptionWhenThreadIsInterruptedAndServiceIsNotDisposing`
case)
Issue Time Tracking
-------------------
Worklog Id: (was: 1045331)
Remaining Estimate: 0h
Time Spent: 10m
> Concurrent Bug while having 2 DatagramAcceptors
> -----------------------------------------------
>
> Key: DIRMINA-1140
> URL: https://issues.apache.org/jira/browse/DIRMINA-1140
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.21
> Reporter: Alexander B
> Assignee: Jonathan Valliere
> Priority: Major
> Labels: bug
> Attachments: CmdException.JPG, MinaDatagramException.zip,
> Send-UdpDatagram.ps1, exception.PNG, minaException.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello,
> We have created 2 DatagramAcceptors running completely independently.
> It seems, that just one at a time is working. We receive
> java.concurrent-Exceptions sometimes.
> These exceptions are thrown from a running thread, which do not have any
> calling classes from our code. Attached you will find the complete exception
> stack.
> Do you have any ideas about this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
