camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: [HEADS UP] - Improved lifecycle and management of routes in Camel 2.5
Date Wed, 04 Aug 2010 03:09:42 GMT
Christian Schneider wrote:
> 
> 
> Am 03.08.2010 06:04, schrieb Claus Ibsen:
>>
>> Yes you need to differentiate between resume/start in your business 
>> logic.
>> The consumer most often need to different logic. For example a HTTP
>> consumer may have to setup and start a HTTP server.
>> Where as in resume it just need to accept requests instead of sending
>> back http status 503 (temporary out of service).
>>
>> Keep the states/methods separated makes it easier to implement and 
>> understand.
>>
>> If you extend ServiceSupport then you got these callbacks you can 
>> override:
>> - doStart
>> - doStop
>> - doResume
>> - doSuspend
>> - doShutdown (special when CamelContext is shutting down)
>>
> That is a good idea to keep these methods simple.
If we don't want to support manage the route dynamically, doStart and 
doStop are enough, but we are not.

doResume and doSuspend are trying to provides a way let the camel 
context hold the endpoint states, and don't destroy or create the 
consumer or producer again.

>>
>> But the logic in the startRoute, resumeRoute has built in so they
>> handle if you invoke either one.
>> So if a route is suspended and your invoke startRoute then it knows
>> that it should resume the route. And vice versa. So from a management
>> point of view in JMX it should not be confusing.
>>
> This also sounds good. The only problem is then that users will probably 
> understand the diagram in the documentation
> as how the management methods work. So it could be confusing that e.g. 
> startRoute also works from suspended state.
> But as I guess that all the transitions in the diagram work as explained 
> the diagram does not explain anything wrong.
>> stop ->  suspend is a bit harder, due you would need to start it and
>> then suspend it immediately, but there is a "window" where the route
>> is actually started, and it could potentially take in messages. And
>> routes can most often start very fast. Well there may be some WS
>> components who parse WSDL files etc which may take some time. We could
>> introduce a doWarmUp callback which is invoked when CamelContext is
>> starting up. It would then allow to pre parse the WSDL files etc. so
>> the consumer is "almost ready".
>>
> I do not think this is really necessary. I only proposed the transition 
> for completenes. A warmup method makes the interface more complex and 
> offers
> not so much value as camel is already starting quite fast.
> 

+1 for not adding the doWarmUp API, as we don't gain much benefit from it.

> Btw. I also think shutdown could be renamed to remove. Without any more 
> knowledge I would interpret shutdown as something that can be reversed 
> by start. So remove is much clearer.
> 
> Greetings
> 
> Christian
>>
>>
>>
> 

Willem


Mime
View raw message