Quantcast

Stoping SEDA and thread interruption

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Stoping SEDA and thread interruption

Vincenzo De Vivo
Hi,
we have the following route starting with a SEDA queue:

RouteDefinition sedaMediaRoute = from("seda:test?concurrentConsumers=2
> &size=10");
> sedaMediaRoute.setId(MEDIA_PROCESSOR_QUEUE_ROUTE_ID);
> sedaMediaRoute.to("bean:testProcessor");
>

We are stopping the route in this way:

camelContext.stopRoute(MEDIA_PROCESSOR_QUEUE_ROUTE_ID, 1, TimeUnit.SECONDS);

When the queue stops, the third librery used in the testProcessor
throws an *ClosedByInterruptException *because it reveals the thread
interruption during an I/O operation.

Now we are wondering if it were possible to stop the SEDA queue,
stopping the consumers from picking up new messages, without
interrupting the execution of the threads
that are still processing exchanges from testProcessor onwards, in
order to not throw the reported exception.

Thank you very much.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Stoping SEDA and thread interruption

Claus Ibsen-2
Dont use so little timeout with only 1 second, set it as a higher value

On Fri, Feb 17, 2017 at 4:06 PM, Vincenzo De Vivo <[hidden email]> wrote:

> Hi,
> we have the following route starting with a SEDA queue:
>
> RouteDefinition sedaMediaRoute = from("seda:test?concurrentConsumers=2
>> &size=10");
>> sedaMediaRoute.setId(MEDIA_PROCESSOR_QUEUE_ROUTE_ID);
>> sedaMediaRoute.to("bean:testProcessor");
>>
>
> We are stopping the route in this way:
>
> camelContext.stopRoute(MEDIA_PROCESSOR_QUEUE_ROUTE_ID, 1, TimeUnit.SECONDS);
>
> When the queue stops, the third librery used in the testProcessor
> throws an *ClosedByInterruptException *because it reveals the thread
> interruption during an I/O operation.
>
> Now we are wondering if it were possible to stop the SEDA queue,
> stopping the consumers from picking up new messages, without
> interrupting the execution of the threads
> that are still processing exchanges from testProcessor onwards, in
> order to not throw the reported exception.
>
> Thank you very much.



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Loading...