On Tuesday, September 13, 2011 1:38:44 PM Nishant Chandra wrote: > I can confirm we are using 2.3.3. In production, I saw 300 threads in > blocked state. > > So to be clear, if I upgrade, I can keep a single instance of port and > there should be no contention issues? > No client connection pooling is required? How are others dealing with it?
As long as you don't use the request context or change the request context to a thread local (see faq), you should fine. I haven't seen this issue from anyone since 2.3.1 was released which made some changes. I would suggest trying to update to 2.4.2 or 2.3.6 and seeing if it helps (and then get new stack traces if not). Dan > > Nishant > > On Tue, Sep 13, 2011 at 2:00 AM, Daniel Kulp <[email protected]> wrote: > > On Tuesday, September 13, 2011 1:30:38 AM Nishant Chandra wrote: > >> I am using v2.3.3. > > > > The put isn't on line 312 for 2.3.3. either. It looks like version > > 2.2.6 or 2.2.7 as those are the only 2 versions that have it on 312. > > > >> Both v2.4.2 line 354 and v2.3.6 line 345 has the put call. > > > > Definitely try with 2.4.2. There have been a bunch of changes with the > > context handling since 2.2.x . > > > > Dan > > > >> Nishant > >> > >> On Mon, Sep 12, 2011 at 9:53 PM, Daniel Kulp <[email protected]> wrote: > >> > On Monday, September 12, 2011 3:59:45 PM Nishant Chandra wrote: > >> >> Hi All, > >> >> > >> >> I have problem with the sync client code generated using > >> >> wsdl2java for a JAX-WS service. I see the following exception > >> >> in logs: > >> >> > >> >> "TP-Processor2070" daemon prio=10 tid=0x00002aaac4cf0800 > >> >> nid=0x161c > >> >> waiting for monitor entry [0x00000000456de000] > >> >> java.lang.Thread.State: BLOCKED (on object monitor) > >> >> at > >> >> java.util.Collections$SynchronizedMap.put(Collections.java:1979) > >> >> - > >> >> waiting to lock <0x00000007957feee8> (a > >> >> java.util.Collections$SynchronizedMap) > >> >> at > >> >> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:312) > >> > > >> > What version of CXF are you using? I just went back through > >> > about a > >> > year of changes to ClientImpl and do not see a "put" on line 312 > >> > for > >> > any of the recent versions. Can you try updating to CXF 2.4.2? > >> > > >> > > >> > Dan > >> > > >> >> at > >> >> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:262) > >> >> at > >> >> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java: > >> >> 73) > >> >> at > >> > > >> > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java > >> > :124)>> > > >> >> at $Proxy107.echo(Unknown Source) > >> >> > >> >> We are using a singleton instance of the EServiceClient across > >> >> our > >> >> App: > >> >> > >> >> class EServiceClient { > >> >> > >> >> private static EServiceClient client = new EServiceClient(); > >> >> > >> >> public static MyServiceClient getInstance() { > >> >> return client; > >> >> } > >> >> > >> >> private RecommendationsServiceClient() { > >> >> initClient(); > >> >> } > >> >> > >> >> private void initClient() { > >> >> > >> >> try { > >> >> URL wsdlURL = EService.WSDL_LOCATION; > >> >> EService ss = new EService(wsdlURL, SERVICE_NAME); > >> >> port = ss.getEServicePort(); > >> >> RECIEVE_TIMEOUT = new Long(timeout); > >> >> CONNECTION_TIMEOUT = new Long(conTimeOUt); > >> >> final Client cl = ClientProxy.getClient(port); > >> >> final HTTPConduit http = (HTTPConduit) cl.getConduit(); > >> >> final HTTPClientPolicy httpClientPolicy = new > >> >> HTTPClientPolicy(); > >> >> httpClientPolicy.setReceiveTimeout(RECIEVE_TIMEOUT); > >> >> httpClientPolicy.setAllowChunking(false); > >> >> httpClientPolicy.setConnectionTimeout(CONNECTION_TIMEOUT); > >> >> http.setClient(httpClientPolicy); > >> >> } catch (Exception e) { > >> >> e.printStackTrace(); > >> >> } > >> >> } > >> >> > >> >> Is it that the 'port' is not thread safe that I am seeing this > >> >> exception? How can I fix it? > >> >> The other problem is that connection timeout values are not > >> >> honored. > >> >> Please help. > >> >> > >> >> Nishant > >> > > >> > -- > >> > Daniel Kulp > >> > [email protected] > >> > http://dankulp.com/blog > >> > Talend - http://www.talend.com > > > > -- > > Daniel Kulp > > [email protected] > > http://dankulp.com/blog > > Talend - http://www.talend.com -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
