Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C96B6F0F2 for ; Sat, 23 Mar 2013 07:15:48 +0000 (UTC) Received: (qmail 38052 invoked by uid 500); 23 Mar 2013 07:15:47 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 37557 invoked by uid 500); 23 Mar 2013 07:15:45 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 37512 invoked by uid 99); 23 Mar 2013 07:15:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Mar 2013 07:15:43 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ullgren@gmail.com designates 209.85.128.176 as permitted sender) Received: from [209.85.128.176] (HELO mail-ve0-f176.google.com) (209.85.128.176) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Mar 2013 07:15:39 +0000 Received: by mail-ve0-f176.google.com with SMTP id cz10so3862323veb.35 for ; Sat, 23 Mar 2013 00:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=9BvqXYTT2a1hj5QKMkYc/yGR/zEMERr2PX1trp8K6ow=; b=x4wffwY7aKai5oHuATLmv28sdKMxYrZrhmAaRk30uEv8ydUe3NME2FPVUbaoAsPjdj yX6w4sX3BLS/0/ohOt6akcoTkV4j1yzyi/U3FmGOi20nq/QBNE//CbL/OMVVnuLSWKq9 B4066azMZSSwIdBFw62CzPHxPqTmn79/mf68qSAxgCL9lOVLeGJUNXPU07vpvx0v1C8x iRktUuJCiv0lS0yK/Utlgxqih1hr0NZfOzWXF4ZyUMN2RaO25Ut2U8JrlHdD88nWfqGS JlB6Ge/IRu29HHGLgaDEyiTeh09z+v8JebZco5HFZWz5cOGNyLH1WQeRYs4+U5JUJcXS 4QTg== MIME-Version: 1.0 X-Received: by 10.52.90.39 with SMTP id bt7mr4930431vdb.110.1364022918479; Sat, 23 Mar 2013 00:15:18 -0700 (PDT) Received: by 10.58.98.3 with HTTP; Sat, 23 Mar 2013 00:15:18 -0700 (PDT) Received: by 10.58.98.3 with HTTP; Sat, 23 Mar 2013 00:15:18 -0700 (PDT) In-Reply-To: References: Date: Sat, 23 Mar 2013 08:15:18 +0100 Message-ID: Subject: Re: How to schedule FTP with quartz? From: Pontus Ullgren To: users@camel.apache.org Content-Type: multipart/alternative; boundary=20cf3071cdc885867304d89255c9 X-Virus-Checked: Checked by ClamAV on apache.org --20cf3071cdc885867304d89255c9 Content-Type: text/plain; charset=UTF-8 This is probably because your route is autoStart=false. So you the first time you need to start it. In my example you see I set both the start and resume schedule to the same cron expression. So the policy will trigger both a start and a resume action. And you will get a WARN log since the first time it can not resume (but it will start) and after that it can not start but it will resume. Perhaps if you share some code it would be easier to help you. //Pontus On 22 Mar 2013 22:06, "Chris Wolf" wrote: > I found the issue with my custom CronScheduledRoutePolicy - initially > the startTime/resumeTime are only scheduled in > onInit() - so to re-resume (re-start), you need to call > scheduleRoute(Action.RESUME, route); in onStart() > > ...but now I'm getting: > > quartz.ScheduledRoutePolicy WARN Route is not in a started state and > cannot be resumed. The current route state is Suspended > > What is the deal? I thought resumeRoute was the inverse of > suspenRoute, but this log message seems to indicate that > calling CamelContext.suspendRoute(routeId) will put the route into a > state that cannot be resumed. > > Thanks, > > > Chris > > On Fri, Mar 22, 2013 at 4:04 PM, Chris Wolf wrote: > > Pontus, > > > > Thanks for that. Since I already has started implementing a class > > derived from CronScheduledRoutePolicy, I just finished it. > > It works by starting a Timer thread in onStart/onResume at the end of > > the time period, the route is suspended, but then upon > > the next schedule cron start time, I don't see it being resumed - I > > wonder if the RoutePolicy itself is being suspend too? > > > > Well, I try it your way also. > > > > > > Thanks, > > > > > > Chris > > > > On Wed, Mar 20, 2013 at 4:34 AM, Pontus Ullgren > wrote: > >> Hello, > >> > >> On Tue, Mar 19, 2013 at 11:22 PM, Chris Wolf > wrote: > >>> On Mon, Mar 18, 2013 at 4:57 PM, Pontus Ullgren > wrote: > >>>> Hello Chris, > >>>> > >>>> On Mon, Mar 18, 2013 at 8:54 PM, Chris Wolf > wrote: > >>>>> Claus, > >>>>> > >>>>> I have a few further questions about CronScheduledRoutePolicy. I > >>>>> noticed that it has setters such as setRouteStartTime, > >>>>> setRouteStopTime, each which takes a cron expression string. What > I'm > >>>>> looking for is to be able to use a cron expression for the start, but > >>>>> a relative time length for stop. Otherwise, I need to write code to > >>>>> parse the start time expression, then calculate a stop time cron > >>>>> expression. Any ideas? > >>>>> > >>>> Depending on your needs you could enable "sendEmptyMessageWhenIdle" on > >>>> the endpoint and then suspend the route when you receive a empty > >>>> message. Which means that there is no more files to poll at the > >>>> moment. > >>>> You can use the content based route EIP for this. > >>> > >>> That is interesting to know, thanks. In my case, the files at the > >>> remote end are themselves deposited at an irregular rate, but within a > >>> defined time window, so during that time window, there will be > >>> intermittent idleness... > >>>> > >>>> Another solution would be to write your own RoutePolicy to take care > >>>> of your needs. > >>> > >>> Yes, this sounds like the best approach... > >>> > >>> > >>>> > >>>> I just started to wonder if it might be possible to combine the > >>>> CronScheduledRoutePolicy with a SimpleScheduledRoutePolicy. > >>>> I have _not_ tested this so I'm not sure if it works. It might be that > >>>> there is a collision in the way they work with Quartz. > >>>> > >>>>> Also I see that CronScheduledRoutePolicy has setRouteResumeTime, > >>>>> setRouteSuspendTime such that for my FTP poll window, I could either > >>>>> do start/stop or resume/suspend - which is recommended? > >>>>> > >>>> I would highly recommend resume/suspend. > >>>> I've had some thread leak problem with the file component when it was > >>>> repetitively started/stopped. > >>> > >>> Ok, but I guess the first policy callback with be onStart since the > >>> route will be > >>> configured with noAutoStartup(), so upon that first onStart, I'll > >>> suspend then toggle > >>> between onSuspend/onResume... > >>> > >> Yes this is what I do. We have a route that should start 06:30 each > >> day and then poll all files that are in the folder at that time. > >> After that it should suspend. > >> > >> Here is some pseudo code. > >> SuspendRouteProcessor is a processor that suspends the route based on > route id. > >> --- > >> String cronStr = "* 30 6 * * * ?"; > >> String input = "ftp://user@remotehost > /inbox?sendEmptyMessageWhenIdle=true&password=secret"; > >> CronScheduledRoutePolicy scheduledRP = new CronScheduledRoutePolicy(); > >> scheduledRoutePolicy.setRouteStartTime(cronStr); > >> scheduledRoutePolicy.setRouteResumeTime(cronStr); > >> > >> from(input) > >> .routeId("input1") > >> .routePolicy(versionPolicy, scheduledRoutePolicy) > >> .noAutoStartup() > >> .choice() > >> .when(body().isNotNull()) > >> .to("direct:processFiles") > >> .end() > >> .log(LoggingLevel.DEBUG, "All files processed, suspend > route") > >> .process(new SuspendRouteProcessor("input1")) > >> ; > >> -- > >> > >> The only downside with this is that after the initial start we get a > >> WARN log message that the route can not be started since it is in > >> suspend state. > >> But as long as you can live with the WARN log it works. > >> > >>>> > >>>> // Pontus > >>>> > >>>>> Thanks, > >>>>> > >>>>> Chris > >>>>> > >>>>> On Sat, Mar 2, 2013 at 1:43 AM, Claus Ibsen > wrote: > >>>>>> Hi > >>>>>> > >>>>>> See about route policy > >>>>>> http://camel.apache.org/routepolicy > >>>>>> > >>>>>> And the scheduled route policy > >>>>>> http://camel.apache.org/scheduledroutepolicy.html > >>>>>> > >>>>>> On Sat, Mar 2, 2013 at 12:15 AM, Chris Wolf > wrote: > >>>>>>> I have a requirement to download files via FTP during a certain > time > >>>>>>> window and according to a schedule. e.g. Only on trading days > between > >>>>>>> 6:30AM and 7:00AM. The FTP component, alone, seems to just do > >>>>>>> indefinite polling according to delay/initialDelay. > >>>>>>> > >>>>>>> From the "Camel In Action" book, chapter 7, I see some examples of > >>>>>>> sending a text message with the Timer and Quartz components, but I > >>>>>>> can't quite see how to put that together to implement "kicking off > >>>>>>> routes at specified intervals", mentioned in the best practices > list > >>>>>>> at the end of that chapter. How would I use quartz to stop/start > the > >>>>>>> FTP component, or the route that it's in? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Chris > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Claus Ibsen > >>>>>> ----------------- > >>>>>> Red Hat, Inc. > >>>>>> FuseSource is now part of Red Hat > >>>>>> Email: cibsen@redhat.com > >>>>>> Web: http://fusesource.com > >>>>>> Twitter: davsclaus > >>>>>> Blog: http://davsclaus.com > >>>>>> Author of Camel in Action: http://www.manning.com/ibsen > --20cf3071cdc885867304d89255c9--