camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: MINA component potential issues
Date Mon, 25 Feb 2008 08:55:17 GMT
On 22/02/2008, Roman Kalukiewicz <> wrote:
> Hello Guys!

Hey Roman!

>  I was looking into MINA camel component and I have few quick questions
>  about it and some potential issues (I think)
>  It looks to me, that mina endpoint establishes connection (when used
>  as a producer) with remote endpoint at the moment it starts. It
>  creates potential problem when you start your context and there is no
>  remote server up - it simply fails instead of establishing connection
>  'lazily' (I think it deserves an issue).

We could lazily create connection when the producer is actually used I
guess.  Sometimes folks wanna know if things are gonna barf up front
rather than waiting much longer; so I guess a flag for eager / lazy
connection creation could be a good thing.

>  Another question is if every request to mina endpoint will be
>  serialized? I looks to me, that it is true, as there is only one
>  socket opened (but sometimes it is preferable). I don't know mina very
>  much, so if it is not true, then let me know, please ;-)

Currently yes - one endpoint tends to use a single connection under
the covers so things are serlialized.

We could introduce some kinda pooling I guess (or making the send
asynchronous maybe).

>  Moreover I've seen that in producer we have a timeout for reading the
>  response for initial request (if you operate as InOut). Is it possible
>  (because it looks to me, that it is), that because of long processing
>  on server side some request receives a response for already timeouted
>  previous request?

Yes its possible. One of the problems with a generic MINA component is
it can't know too much about how a transport is being used; so its a
tad hard to look at a response and do multiplexing like we can do with
JMS with JMSCorrelationID type stuff for example.

For many threads doing request/reply; if there was some kinda
correlation/thread ID in the response, we could have a single thread
reading the responses and dispatching them to the right thread. If
thats not possible, it might be easier for each Producer to have its
own Connection.

>  I know that I could test all those things myself, but if you already
>  know the answer, please reply ;-)



Open Source Integration

View raw message