Ok, I misunderstood the "Stopping a route during routing an existing message is 
a bit tricky. The reason for that is Camel will Graceful Shutdown the route you 
are stopping. And if you do that while a message is being routed the Graceful 
Shutdown will try to wait until that message has been processed." Which made me 
think the Processor method described an alternate way and therefore would stop 
the route during the message transfer. In fact you are saying it is an 
equivalent operation, I think. 

Since I am doing this in code I am not sure which of the many impl of 
ProcessDefinition I should be adding to a RouteContext and then adding to the 
Route. 

Is it like this?

        RouteDefinition routeD = new RouteDefinition(); 
              routeD.from(sourcePath);

        routeD.to(localPath+"?fileExist=Override");
        RouteContext rContext = new DefaultRouteContext(camelContext);
        ProcessorDefinition pDefn = ?
        rContext.createProcessor(pDefn);
        routeD.createProcessor(rContext);
        routeDefn.put(sourcePath+localPath+"?fileExist=Override", routeD);
            camelContext.addRouteDefinition(routeD);
                camelContext.startRoute(routeD);

Not sure which ProcessorDefinition type I need.

Thx.

David

________________________________
 From: Taariq Levack <taar...@gmail.com>
To: "users@camel.apache.org" <users@camel.apache.org> 
Sent: Thursday, 29 December 2011, 17:50
Subject: Re: NPE for FTP endpoint
 
Hmmm, can you talk more about your use case? 
Because the FAQ seems a perfect fit, you consume the file and then stop the 
route, later it starts again in whatever way you want.

No idea on the NPE, sorry.

Taariq

On 29 Dec 2011, at 7:29 PM, David Wynter <david_wyn...@yahoo.com> wrote:

> Hi,
> 
> I do not want to stop the route mid flight as that FAQ seems to be 
> suggesting. I would be happy to use DefaultShutdownStrategy, if it worked. My 
> problem is that it is inconsistent, which seems bad design, on a slow machine 
> the route is not considered started by the time I hit the stopRoute, whereas 
> on a fast machine it is considered started. I even used Thread delays but 
> that did not give consistent results either. Thus I decided to leave the 
> route running, but that polls the server, a no no with this service provider. 
> There does not seem a way to just do it once and then be certain the fetch 
> has occurred before stopping the route to prevent the polling. I'd like to 
> poll until my fetch from the ftp server is complete, and then stop polling 
> and stop the route, I'll start it again when I am ready. There does not seem 
> to be a way of adding a listener to the route to ask it, "hey have you 
> actually completed the route for the file specified?" The only way I
> can think of doing this is adding a custom endpoint as a next step, this 
> custom endpoint then calls for the route to be stopped.
> 
> But these are the least of my worries since on my customers machine I get the 
> NPE, but in testing here I do not? Any ideas on this NPE?
> 
> Thx.
> 
> David
> 
> 
> ________________________________
> From: Taariq Levack <taar...@gmail.com>
> To: "users@camel.apache.org" <users@camel.apache.org> 
> Sent: Thursday, 29 December 2011, 17:14
> Subject: Re: NPE for FTP endpoint
> 
> Hi
> 
> Did you try this FAQ[1] on how to stop a route from a route?
> [1] http://camel.apache.org/how-can-i-stop-a-route-from-a-route.html
> 
> Taariq
> 
> On 29 Dec 2011, at 6:12 PM, David Wynter <david_wyn...@yahoo.com> wrote:
> 
>> Hi,
>> 
>> I tested on my machine and deployed to my customer, It went boom as follows, 
>> names etc. changed to protect the innocent.
>> 
>> All I want to do with this route is grab a file from a ftp service, once, 
>> don't poll it annoys them, leave the file intact on their server. I will 
>> control when this route is run externally. I tried it with start() follow by 
>> stop(), 
>> 
>>             camelContext.addRouteDefinition(routeD);
>>                 camelContext.startRoute(routeD);
>> but the DefaultShutdownStrategy is flaky, on a slow machine it does not 
>> consider the route started before the stop() is hit, whereas on a fast 
>> machine it does. So I am forced to leave the route running

Reply via email to