I've submitted a patch here:
https://issues.apache.org/jira/browse/DIRMINA-615
Ultimately, I didn't require anything to fix my problem other than to
make the NioProcessor class non-final. For my convenience, I've
exposed two additional constructors in NioDatagramConnector, and for
consistency, I've exposed those same constructors in
NioSocketConnector.
Barend
On Mon, Aug 11, 2008 at 6:00 PM, W.B. Garvelink
<[EMAIL PROTECTED]> wrote:
> Update: I've found the cause of the problem (it wasn't what I originally
> thought, but it does require patching MINA a bit) and a strategy to fix it.
> The
> rest of this message is basically FYI. Details of my intended patch are in the
> last paragraph.
>
> Earlier, I wrote:
>> The scheduleFlush() call returns false because AbstractPollingIoSession#
>> setScheduledForFlush(true) does. Apparently, the AbstractIoSession#
>> scheduledForFlush boolean is still set to true
>
> Since I wrote that, I've narrowed the problem down a bit. Part of the problem
> was in the way I was testing my ARQ code: I simply started the client but no
> server, then sent a packet and waited for the time-outs to flow by. What I
> neglected to mention in my original post was the PortUnreachableException that
> gets thrown when there's nothing at the endpoint address.
>
> As these things go, it was *of course* this exception and not that boolean
> flag that was ultimately causing the writes to stall. I wrote a dummy
> program that opens a DatagramSocket on the server port number, but never
> sends any ACK packets, and immediately, the client writes its retries to the
> network the way I expect it to.
>
> Here's the relevant bit of code from AbstractPollingIoProcessor#flush():
>
>> try {
>> boolean flushedAll = flushNow(session);
>> // (schedule next flush if it didn't write all of it at once)
>> }
>> catch (Exception e) {
>> scheduleRemove(session);
>> session.getFilterChain().fireExceptionCaught(e);
>> }
>
> I assume the scheduleRemove(session) is ultimately responsible for my
> earlier problem.
>
> Having that cleared up, this does bring me to a second problem, and this
> is where it gets interesting.
>
> When it goes live this application is going to be, by design, a second-
> class citizen on the network on which it operates. Whenever it gets muted
> for higher priority data, the network driver simply drops its data on the
> client side and generates ICMP Unreachable errors to notify the calling
> application.
>
> This means that these PortUnreachableExceptions are going to be a very
> common thing. Clearly, I can deal with this by supplying my own IoProcessor
> instance when I construct the endpoints. However, with the current MINA code,
> that means copying not only the NioProcessor concrete class, but also the
> AbstractPollingIoProcessor, as there's no suitable hook for me to use.
>
> I'll submit a patch that changes the catch block quoted above to forward
> to an overrideable method that implements the current behaviour by default
> (wait for a JIRA issue tonight or tomorrow) as I suspect that this "intercept
> the exception before anything gets removed" may be useful for other people
> as well. It'll also make the NioProcessor class non-final.
>
>
> Regards,
> Barend
>
