No connection reuse with recipientList and Mina Endpoints

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

No connection reuse with recipientList and Mina Endpoints

Jеns Riеmschneidеɾ
Hi,

I have run into an issue with a .recipientList() using Mina endpoints (Camel 2.1). Basically, I was changing a route from using static .to() calls into a more dynamic .recipientList() call. With the .to() calls IoSessions were reused to send data. However, with the .recipientList() it seems that the IoSessions are created for each message. They are not closed immediately after sending the message, but are held for quite some time. In the end our server side refused additional connections until a timeout occurred and the sessions were closed.

The reason for this seems to be the way that the recipient list retrieves producers from the producer cache. From the source code of RecipientList.java:

        while (iter.hasNext()) {
            Object recipient = iter.next();
            Endpoint endpoint = resolveEndpoint(exchange, recipient);
            Producer producer = getProducerCache(exchange).getProducer(endpoint);
            processors.add(producer);
        }

There is a comment in ProducerCache.getProducer that says the producer pool is not used because it cannot be guaranteed that the producer is returned to the pool.
I changed our implementation back to using .choice() and .to() calls. But it would be nice to have the recipient list functionality with Mina endpoints.

Thanks,
Jens
Reply | Threaded
Open this post in threaded view
|

Re: No connection reuse with recipientList and Mina Endpoints

Claus Ibsen-2
Hi

This should be fixed in Camel 2.3.



On Wed, Mar 31, 2010 at 9:46 AM, _Jens <[hidden email]> wrote:

>
> Hi,
>
> I have run into an issue with a .recipientList() using Mina endpoints (Camel
> 2.1). Basically, I was changing a route from using static .to() calls into a
> more dynamic .recipientList() call. With the .to() calls IoSessions were
> reused to send data. However, with the .recipientList() it seems that the
> IoSessions are created for each message. They are not closed immediately
> after sending the message, but are held for quite some time. In the end our
> server side refused additional connections until a timeout occurred and the
> sessions were closed.
>
> The reason for this seems to be the way that the recipient list retrieves
> producers from the producer cache. From the source code of
> RecipientList.java:
>
>        while (iter.hasNext()) {
>            Object recipient = iter.next();
>            Endpoint endpoint = resolveEndpoint(exchange, recipient);
>            Producer producer =
> getProducerCache(exchange).getProducer(endpoint);
>            processors.add(producer);
>        }
>
> There is a comment in ProducerCache.getProducer that says the producer pool
> is not used because it cannot be guaranteed that the producer is returned to
> the pool.
> I changed our implementation back to using .choice() and .to() calls. But it
> would be nice to have the recipient list functionality with Mina endpoints.
>
> Thanks,
> Jens
> --
> View this message in context: http://old.nabble.com/No-connection-reuse-with-recipientList-and-Mina-Endpoints-tp28092450p28092450.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Reply | Threaded
Open this post in threaded view
|

Re: No connection reuse with recipientList and Mina Endpoints

peter.berkman
we are still seeing this exact issue in Camel 2.10.2 using Spring routes.

is there a bug ticket that this was fixed against?   we can add what we are seeing.

Basically, when using the recipientList and Mina to send to different host/ports, depending on memory available, it runs fine for anywhere between 2-12 hours, then starts consistently throwing "Unable to connect..." failures until the container is restarted.