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? 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 >
