For the question of the system property part, how about using the CamelContext properties[1] to set timeout variable's value.
[1] http://willemjiang.blogspot.com/2009/03/set-properties-for-camel-context.html Willem Claus Ibsen wrote: > On Wed, May 27, 2009 at 12:21 AM, harinair <[email protected]> wrote: >> Claus: >> >> I believe many components have the option of setting timeout. HTTPClient >> used by HTTP component internally have a timeout setting >> (HttpConnectionParams.setConnectionTimeout(): >> http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/params/HttpConnectionParams.html#setConnectionTimeout(int) > This is the connection timeout, eg when establishing a connection. > > There is another timeout - the SO timeout > http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/params/HttpMethodParams.html#setSoTimeout(int) > > And you can set this already with Camel. See the http page: > http://camel.apache.org/http.html > > >> Same may be the case for FTP/SFTP. My problem is if a client has a bad >> server and does not release the connection, my delivery queues start filling >> up since the outbound message delivery component (like HTTP/SFTP) is stuck >> in a timeout. If the underlying layer does not have an easy timeout setting >> then it becomes difficult. Your idea of a separate thread to monitor timeout >> may be necessary. But still, is there any way we know for sure that the >> connection has timed out or it is busy transferring a huge chunk of data? >> >> As a user, the best scenario for me is to have a >> -Dorg.camel.CONNECT_TIMEOUT=XX and -Dorg.camel.READ_TIMEOUT=XX system >> properties that will set the connect / read timeouts. > System properties is really not something I am in favor of. Many > operation environments you are not allowed to tamper with start/stop > scripts of their existing infrastructure. For instance who is allowed > to tamper with the start script of WebSphere. > > The timeouts should be configured in a configuration file like all the > others. Camel should have a global and then per. produder/consumer > that can overrule the global. > > Some of the components have timeout values: > - JMS > - Mina > - Http > > But I do not recall if the FTP have one. However it supports automatic > re-connection. > > We could have it on the roadmap for Camel 2.1+ to investigate if its > possible to have such a generic timeout configuration. > > > >> What do you think? >> >> Hari Gangadharan >> Architect, Globalstar >> http://www.harinair.com >> >> >> Claus Ibsen-2 wrote: >>> Hi >>> >>> >>> On Thu, May 21, 2009 at 9:49 PM, harinair <[email protected]> wrote: >>>> I am using Camel to send messages from a Queue to external vendors. The >>>> protocol can be FTP/SFTP/HTTP or HTTPS. However sometimes the queue >>>> starts >>>> filling up which means that the messages are not getting drained. My >>>> feeling >>>> is the connection to a particular external vendor is stuck because the >>>> timeout is not properly set. My DSL is similar to: >>>> <bean id="dataPushErrorHandler" >>>> class="org.apache.camel.builder.DeadLetterChannelBuilder"> >>>> <property name="defaultDeadLetterEndpointUri" >>>> value="seda:routerDeliveryAttempt1Queue" /> >>>> <property name="redeliveryPolicy" ref="dataPushRedeliveryPolicy" >>>> /> >>>> </bean> >>>> >>>> <!-- Deliver the Live Data Push - Channel A data --> >>>> <route errorHandlerRef="dataPushErrorHandler"> >>>> <from ref="routerDeliveryChannelAQueue" /> >>>> <process ref="securityHeaderGenerator" /> >>>> <to ref="routerLogDefault" /> >>>> <recipientList> >>>> <xpath resultType="java.lang.String">$routerRoute</xpath> >>>> </recipientList> >>>> <to uri="bean:responseVerificationProcessor?method=process" /> >>>> </route> >>>> >>>> >>>> Now my questions is - is there any easy global parameter to set the >>>> timeout >>>> for all network operations done by Camel? If there is not is there any >>>> way I >>>> can set timeout for FTP/SFTP/HTTP modules? Is it a good idea to add a >>>> global >>>> timeout or to use sun.net.client.defaultConnectTimeout and >>>> sun.net.client.defaultReadTimeout? >>> Yeah timeout setting is actually hard as well. >>> You got the OS level, the JVM, the JVM system properties, the >>> framework and then Camel as well. >>> And they all got different/independent timeout and whatnot. >>> >>> >>> A general timeout feature does not exists in Camel. Some of the >>> transports offer a timeout. >>> - JMS >>> - Mina >>> - and maybe some others but I cannot remember. But its documented in >>> the wiki if they have a timeout option >>> >>> However we could consider having a Camel timeout feature so Camel at >>> least could and indicate a timeout error. >>> However its not easy to do with all protocols. And we need some latch >>> around that can trigger when a timeout occur. >>> >>> But I do think we could add something to the SendToProcessor that can >>> support a custom Camel timeout that kinda overrule any other. >>> But this requires a latch and to use a different thread for sending. >>> Or am I wrong on this? >>> >>> Any thought? >>> >>> >>> >>> >>>> Hari Gangadharan >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Camel-stuck-periodicallly---HTTP-timeout-issue-tp23659334p23659334.html >>>> Sent from the Camel - Users mailing list archive at Nabble.com. >>>> >>>> >>> >>> >>> -- >>> Claus Ibsen >>> Apache Camel Committer >>> >>> Open Source Integration: http://fusesource.com >>> Blog: http://davsclaus.blogspot.com/ >>> Twitter: http://twitter.com/davsclaus >>> >>> >> -- >> View this message in context: >> http://www.nabble.com/Camel-stuck-periodicallly---HTTP-timeout-issue-tp23659334p23732505.html >> Sent from the Camel - Users mailing list archive at Nabble.com. >> >> > > >
