On Sun, May 31, 2009 at 9:58 AM, Willem Jiang <[email protected]> wrote: > 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 Hi
Yeah Willem I am on the same page with you. I would like this new feature to be where we can define such options/configuration on a Camel context. Also for instance the default encoding and what else. > > 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. >>> >>> >> >> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
