[
https://issues.apache.org/jira/browse/DIRMINA-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538692
]
Niklas Therning commented on DIRMINA-375:
-----------------------------------------
Actually, the continuations stuff may be overkill for a single client. In that
situation a simpler one thread per client API would be better. Now if you had
100 clients running in the same JVM things would be different. My plan is to
use continuations for our (www.spamdrain.net) spam filtering proxies. These
proxies are both servers and clients and there could be hundreds or thousands
of connections running simultaneously. In such an environment the one thread
per client type of API wouldn't work.
> Synchronous Client API
> ----------------------
>
> Key: DIRMINA-375
> URL: https://issues.apache.org/jira/browse/DIRMINA-375
> Project: MINA
> Issue Type: New Feature
> Reporter: Brad Harvey
> Fix For: 2.0.0-M1
>
> Attachments: EchoClient.java, minaClient.patch, 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.
