[
https://issues.apache.org/jira/browse/DIRMINA-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Harvey closed DIRMINA-375.
-------------------------------
Hi Trustin,
Looks good. To clarify one of my comments above, I actually prefer throwing
exceptions rather than returning null, but it is better to be consistent with
the rest of the API in this case.
One potential caveat is that if the protocol codec being used can convert
messages into exceptions, then these messages returned from the peer are
indistinguishable from exceptions generated locally that would usually go to
exceptionCaught. Whereas messageReceived would still be called in a
ProtocolHandler, ReadFuture.getMessage() will wrap and throw the exception
instead of just returning it so the behaviour is a little bit inconsistent.
This was why I used a wrapper for the values in my original patch.
I don't know if anyone would actually do this - I don't think it's a serious
issue as long as it is documented.
Cheers,
Brad.
> Synchronous Client API
> ----------------------
>
> Key: DIRMINA-375
> URL: https://issues.apache.org/jira/browse/DIRMINA-375
> Project: MINA
> Issue Type: New Feature
> Reporter: Brad Harvey
> Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
> Attachments: EchoClient.java, minaClient.patch, ReadFutureTest.java,
> SumUpClient.java
>
>
> Hi,
> There was mention of a synchronous client api for MINA on the mailing list,
> so I thought I'd offer my implementation.
> http://www.nabble.com/forum/ViewPost.jtp?post=10445399&framed=y
> As far as I can tell it works, but I've never given it a good run under heavy
> load. The areas I think could use some review are:
> Connection - possible to use generics? Only makes sense if you can tie it to
> what the filters are doing I think.
> ConnectionFactoryImpl - is the managedSessions processing required?
> SequentialExecutor/DaemonThreadFactory - are there better/pre existing ways
> of doing these?
> Connection/NonBlockingConnection - any point having them separate? Did this
> initially for JCA resource adapter idea - didn't want to offer non blocking
> to EJB clients.
> Regards,
> Brad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
