Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 rubancse@gmail.com does not designate 216.139.236.26 as permitted sender)
Date: Tue, 8 Jul 2014 06:10:37 -0700 (PDT)
From: rubancsp <rubancse@gmail.com>
To: users@camel.apache.org
Message-ID: <1404825037830-5753545.post@n5.nabble.com>
In-Reply-To: <etPan.53bb65ee.46e87ccd.11b@localhost>
References: <1358982445128-5726103.post@n5.nabble.com>
 <1359012116101-5726113.post@n5.nabble.com>
 <1404745746800-5753468.post@n5.nabble.com>
 <etPan.53bb65ee.46e87ccd.11b@localhost>
Subject: Re: Possible bug with multicast shareUnitOfWork
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Willem

Thanks for your reply, 

already we are configuring the time out changes in camel-cxf.xml as below
before making the synch call(using worked thread).

<http-conf:conduit
	
name="{http://xml.comcast.com/commercialcustomer/services}CommercialCustomerServicePort.http-conduit">
		<http-conf:client ReceiveTimeout="${workbench.connector.RecieveTimeout}"
			ConnectionTimeout="${workbench.connector.ConnectionTimeout}" />
	</http-conf:conduit>


But still we are getting the stuck thread issue, just wanted to know if
there is any time out setting is available in customized thread pool which
will terminate thread within the configurable amount of time and worked
thread will be reused it for the next transaction,

Thanks
Ruban


--
View this message in context: http://camel.465427.n5.nabble.com/Possible-bug-with-multicast-shareUnitOfWork-tp5726103p5753545.html
Sent from the Camel - Users mailing list archive at Nabble.com.