HTTP thread blocking

I have a flex application that uses livecycle and java WS.
While application is working I get one thread taking a lock on a flex.data.SequenceManager object then never releasing it. I suspect that it is somekind of a core process(not invoked by a user, because user functionality remains ok) but I can be wrong.
i only have the thread stack to define the cause
the thread holding the lock (in runnable state):
java.util.Collections.eq(Unknown Source)
java.util.Collections.access$000(Unknown Source)
java.util.Collections$SingletonMap.get(Unknown Source)
java.util.AbstractMap.equals(Unknown Source)
flex.data.ItemIdentity.equals(ItemIdentity.java:257)
flex.data.ItemIdentity.equals(ItemIdentity.java:257)
java.util.HashMap.get(Unknown Source)
flex.data.SequenceManager.findMostDisplacedItemIndex(SequenceManager.java:3012)
flex.data.SequenceManager.createSequence(SequenceManager.java:2848)
flex.data.SequenceManager.manageSequence(SequenceManager.java:819)
flex.data.SequenceManager.manageSequence(SequenceManager.java:787)
flex.data.DataService.serviceMessage(DataService.java:588)
flex.messaging.MessageBroker.routeMessageToService(MessageBroker.java:1406)
flex.messaging.AsyncMessageBroker.routeMessageToService(AsyncMessageBroker.java:571)
flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:1005)
flex.messaging.endpoints.amf.MessageBrokerFilter.invoke(MessageBrokerFilter.java:103)
flex.messaging.endpoints.amf.LegacyFilter.invoke(LegacyFilter.java:158)
flex.messaging.endpoints.amf.SessionFilter.invoke(SessionFilter.java:44)
flex.messaging.endpoints.amf.BatchProcessFilter.invoke(BatchProcessFilter.java:67)
flex.messaging.endpoints.amf.SerializationFilter.invoke(SerializationFilter.java:165)
flex.messaging.endpoints.BaseHTTPEndpoint.service(BaseHTTPEndpoint.java:293)
flex.messaging.MessageBrokerServlet.service(MessageBrokerServlet.java:364)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.ja va:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
com.adobe.workspace.events.RemoteEventClientLifeCycle.doFilter(RemoteEventClientLifeCycle. java:152)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.ja va:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.ja va:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.jav a:179)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:1 57)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.jav a:580)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Unknown Source)
The thread that is blocked by a flex.data.SequenceManager object:
flex.data.SequenceManager.createSequence(SequenceManager.java:2417)
flex.data.SequenceManager.manageSequence(SequenceManager.java:819)
flex.data.SequenceManager.manageSequence(SequenceManager.java:787)
flex.data.DataService.serviceMessage(DataService.java:588)
flex.messaging.MessageBroker.routeMessageToService(MessageBroker.java:1406)
flex.messaging.AsyncMessageBroker.routeMessageToService(AsyncMessageBroker.java:571)
flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:1005)
flex.messaging.endpoints.amf.MessageBrokerFilter.invoke(MessageBrokerFilter.java:103)
flex.messaging.endpoints.amf.LegacyFilter.invoke(LegacyFilter.java:158)
flex.messaging.endpoints.amf.SessionFilter.invoke(SessionFilter.java:44)
flex.messaging.endpoints.amf.BatchProcessFilter.invoke(BatchProcessFilter.java:67)
flex.messaging.endpoints.amf.SerializationFilter.invoke(SerializationFilter.java:165)
flex.messaging.endpoints.BaseHTTPEndpoint.service(BaseHTTPEndpoint.java:293)
flex.messaging.MessageBrokerServlet.service(MessageBrokerServlet.java:364)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.ja va:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
com.adobe.workspace.events.RemoteEventClientLifeCycle.doFilter(RemoteEventClientLifeCycle. java:152)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.ja va:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.ja va:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.jav a:179)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:1 57)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.jav a:580)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Unknown Source)
can anybody, by any chance, understand what kind of a process is being called from this trace?

Can you maybe remember the month or something so i could search it by meself in the mailing list? Was it the dev mailing list or the community mailing list?

Similar Messages

Weblogic 10 jsp compliation thread block problem

hi
i am using weblogic 10 and jdk1.5.
My application is deployed in ear format, with 2 wars, and 20 ejbs.
The ear works ok with weblogic 8.1.
In the application , one war passes the request to another war, that's the workflow....
Now when the request is passed on the second war, a jsp is supposed to open....but the application get stuck there.
The call is like this in a servlet....
     reqDisp = req.getRequestDispatcher("/newIndex.jsp");
reqDisp.forward(req, res);
The new index jsp is not opened....there is no problem with it it comiples ok....i check with weblogic appc...and it is working on weblogic 8.1.
when i stop the server...the log gives me following exception info.
"ExecuteThread: '12' for queue: 'default'" daemon prio=6 tid=0x2b8edad0 nid=0xc1
0 in Object.wait() [0x2da1e000..0x2da1fb64]
at java.lang.Object.wait(Native Method)
- waiting on <0x07f94608> (a javelin.client.JobWaiter)
at java.lang.Object.wait(Object.java:474)
at javelin.client.JobWaiter.blockUntilFinished(JobWaiter.java:45)
- locked <0x07f94608> (a javelin.client.JobWaiter)
at javelin.client.ClientUtilsImpl.build(ClientUtilsImpl.java:838)
at weblogic.servlet.jsp.JavelinxJSPStub.compilePage(JavelinxJSPStub.java:248)
at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:200)
at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:164)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:235)
- locked <0x07ef8220> (a weblogic.servlet.jsp.JavelinxJSPStub)
at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:391)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:309)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:503)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:245)
at LCDisplayController.handleProcessing(Unknown Source)
at DisplayControllerServlet.doPost(Unknown Source)
at DisplayControllerServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:503)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:245)
at com.orbitech.workflow.servlet.WFAppListController.openWorkitem(WFAppListController.java:793)
at com.orbitech.workflow.servlet.WFAppListController.processRequest(WFAppListController.java:102)
at com.orbitech.workflow.servlet.WFAppController.doProcessRequest(WFAppController.java:97)
at com.orbitech.workflow.servlet.WFAppController.doGet(WFAppController.java:64) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
i think the there is thread blocking and the jsp is not getting compiled or smthing....
i am unable to understnd the exception....
any help, suggestion ? thanks in advance.

We are using jBPM and Hibernate in our application which runs fine on other java application servers. On Weblogic we were getting an error:
org.hibernate.HibernateException: Errors in named queries: GraphSession...........
By adding:
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
to our weblogic.xml, Weblogic used our Hibernate3 and antl-2.7.6 .jar files which resolved this issue but created multiple CompilationException errors in many .jsp's. (as follows)
Error 500--Internal Server Error
weblogic.servlet.jsp.CompilationException: Failed to compile JSP /WEB-INF/jsp/struts/dashboards/portfolio_chart.jsp
portfolio_chart.jsp:1:1: The validator class: "org.apache.taglibs.standard.tlv.JstlCoreTLV" has failed with the following exception: "java.lang.ClassCastException: weblogic.xml.jaxp.RegistrySAXParserFactory".
<%@ taglib uri="/jstl-core" prefix="c" %>
^---------------------------------------^
portfolio_chart.jsp:1:1: The validator class: "com.primavera.pvweb.taglib.JSMessageTagLibraryValidator" has failed with the following exception: "java.lang.ClassCastException: weblogic.xml.jaxp.RegistrySAXParserFactory".
<%@ taglib uri="/jstl-core" prefix="c" %>
^---------------------------------------^
     at weblogic.servlet.jsp.JavelinxJSPStub.compilePage(JavelinxJSPStub.java:298)
     at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:216)
     at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:165)
     at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:235)
     at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:394)
     at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:309)
Is this a Weblogic bug ?

Thread blocking on java.nio.charset.CoderResult

Hello all,
I have a multi-threaded app which does some fairly intestive string operations (basically extracts text from documents for indexing a search system).
I am seeing a massive bottleneck around the java.nio.charset.CoderResult class. When profiling, I see a whole stack of threads blocking on (waiting for) a monitor on this java.nio.charset.CoderResult class. Seems to be a result of string encoding/decoding (I am often encoding strings as UTF-8).
Anyone know why the JVM would want my threads to sync on this class? It's creating a huge performance issue for my app. Approximately 15% of ALL the processing time is spent waiting for this class.
Help!

I would guess that you're using some of the static methods in the CoderResult class. The static methods CoderResult.unmappableCache(), CoderResult.malformedForLength() and CoderResult.malformedCache all use a static inner class called Cache. Its get() method is synchronized on Cache.class. Since the Cache inner-class is static, any part of your multi-threaded application that goes through the Cache.get() method is going to be waiting for the lock on Cache.class.
Could you create a CoderResult instance for each thread? That would mean that there would be a different static Cache class for each thread, reducing the number of threads competing for the Cache.class lock.
I'd have to see some of your code to give a better answer.
Brian

Thread Problem - (Thread Blocking Problems?)

Hi Friends
In my program while using thread i found a problem in this code .
In this whlie running the 'msg' was printen only after all 5 inputs are given .
why i was not getting output after one input.why the thread out was waiting for remaining threads input.
my code is
import java.io.*;
class MyThread extends Thread
BufferedReader bin;
   MyThread()
     super();
     start();
   public void run()
      try
       bin=new BufferedReader(new InputStreamReader(System.in));
       String msg=bin.readLine();
       System.out.println(msg);
      catch(IOException e)
         System.out.println(e);
public class Threads
     public static void main(String args[])
          for(int i=0;i<5;i++)
            new MyThread();
}

Hi Friends
In my program while using thread i found a problem
em in this code .
In this whlie running the 'msg' was printen only
after all 5 inputs are given .
why i was not getting output after one input.why
hy the thread out was waiting for remaining threads
input.Probably because of how the scheduler was rotating among the threads while waiting for input and queueing up output.
When you call readLine, that thread blocks until a line is available. So it probably goes to the next thread's readLine, and so on. All threads are probably blocked waiting for input before you enter a single character.
Something inside the VM has to coordinate the interaction with the console, and between that and your threads, the out stuff just doesn't get a chance to display right away.
In general, you can't predict the order of execution of separate threads.

Thread blocked in printStackTrace

I find one of my thread blocked in printStackTrace after perform an overload test. But it doesn't wait any java lock. So I don't know what happened.
Part of dumped thread stack looked like this:
"Thread: 553" daemon prio=5 tid=0x00598f68 nid=0x23f runnable [95d7f000..95d7fc28]
     at java.lang.Throwable.getStackTraceElement(Native Method)
     at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
     - locked <0xc423b3a8> (a java.lang.Throwable)
     at java.lang.Throwable.printStackTrace(Throwable.java:510)
My application runs on solaris, sparc machine. JVM is 1.4.2_04-b05.

Can u pstack the process at this moment? The stacks of all the threads are probably too large to be shown here.
Show the thread #575. i.e. nid = 0x23f, convert to decimal = 575, maybe its stuck in the native portion.
Hope this helps.

[svn:bz-trunk] 12951: Changed synchronized PropertyProxyRegistry#getRegistry method to non-synchronized to avoid threads blocking in message push .

Revision: 12951
Revision: 12951
Author:   [email protected]
Date:     2009-12-15 02:17:31 -0800 (Tue, 15 Dec 2009)
Log Message:
Changed synchronized PropertyProxyRegistry#getRegistry method to non-synchronized to avoid threads blocking in message push.
Checkintests: Pass with the usual 3-4 tests that time out with and without this change.
QA: Yes
Doc: No
Modified Paths:
    blazeds/trunk/modules/core/src/flex/messaging/io/PropertyProxyRegistry.java

Revision: 12951
Revision: 12951
Author:   [email protected]
Date:     2009-12-15 02:17:31 -0800 (Tue, 15 Dec 2009)
Log Message:
Changed synchronized PropertyProxyRegistry#getRegistry method to non-synchronized to avoid threads blocking in message push.
Checkintests: Pass with the usual 3-4 tests that time out with and without this change.
QA: Yes
Doc: No
Modified Paths:
    blazeds/trunk/modules/core/src/flex/messaging/io/PropertyProxyRegistry.java

XI - HTTP Action Block Error !

Hi Guys!
I have problem when using XI HTTP Action block.
Everthy worked fine few days back , now i get below error strange
[ERROR]: Error: Status (502): Proxy Error ( The specified network name is no longer available. )
[ERROR]: ACTION FAILED: End Action HTTP_XI_0 : ( )
Any reason , i have not changed any settings
rgds
Savy

Hi,
You have to do the Proxy settings in System Management----->System Administration.
Go to the below link for help:
http://help.sap.com/saphelp_xmii120/helpdata/en/45/59840fe39065d1e10000000a1553f6/content.htm
-Suresh

Thread Blocked Problem

I Have a multithread application which:
- access to database
- write files
- read files
- execute external process using exec
What considerations should I take in order to avoid Threads Blocking? When Thread blocking occurs how can I know what is the cause?
Thanks!
T

http://www.ibm.com/developerworks/library/j-thread.html
- Saish

Https pages blocked

Hello,
Recently, safari (I've tried firefox too) cannot open web pages with https such as my bank, hotmail, and every other website I use that has secure pages. The message is: "safari could not open the page ... because the server is not responding." I have tried empty cache, reset safari, repaired permissions, all to no avail. Can anyone please help me?

It seems to be a "security" problem introduced with 10.5.6.
I opened a case with Apple 2 days after the 10.5.6 update came out (I applied the combo update), the only thing you can do is to try to remove the phising check in the Safari prefs, but please be aware that this is not solving the problem.
I was the first one writing (look for my other posts in the forums) of this problem, and now seems that thousands of upgraders (to 10.5.6) are suffering the same issue.
on my macbook all the "standard" operations (init, reset, cache, proxy, security, little snitch, permissions, repair, new user..etc.etc.etc.) didn't solve the problem.
on my g4 powerbook with 10.5.5 the issue is not present.
with my macbook's wife, from scratch to leopard 1.5.6, very same problem, symptoms are:
- around 70% of https sites blocked (problem may be on the new OS process demanded to manage certificates).
- Inability to read and handle the cookies from https sites (it seems that Mac OS believe that the source who want to modify the cookie is not safe... don't ask me why!)
- slowness of dns lookup (it applies on ISP's DNS and also on other DNS sources. eg: OpenDNS).
Temporary solution?
use an "alternative" way to surf... (Parallels, VM..., Sun's VM).
it seems that Opera is "less" affected by the problem (I'm not sure if they use the internal OS procs to check https sites).
The problem, let me highlight again, seems to be on how MacOSX now treats https/certificates/phising/proxies...
Hope to have a solution soon.

Why happens when threads block on I/O?

I want to know what are the reasons for threads blocking on I/O.Do they block to allow the I/O operation or do they block(enter in waiting state) to allow other threads to continue operation while I/O opeation ?
If a particular thread is blocked for I/O do other threads get a chance by the Thread Scheduler ?
If this question has been asked and answered somewhere ,kindly let me know so that i can follow that thread.
Thanks for your consideration.

>
Which thread is that which is "suspended"? The thread which is blocked waiting for the I/O will, um, wait for the I/O. That means it doesn't do anything else. It just waits. That's all. Is that not obvious?
The "suspended" one is the one which is blocked waiting for the I/O.My question is when say the I/O is complete or the stream closes,won't the thread start executing again if given a chance by the scheduler ?
Of course that doesn't affect any other threads. And what do you mean by "related to this thread"? There's no such concept. Each thread operates independently, except when they interact by holding locks or waiting for locks.
"Related to this thread" means thread that share some common resources or say locks.Here i meant any other thread than the one which is blocked for I/O.
Seems to me your mental model of threads is far too complicated. You need to get rid of all those imaginary concepts you're trying to insert there.That is what i am trying to simplify !!!!

Thread Blocking..help

Hi All,
I'm finding it hard to understand the concept of Threads blocking, for example, when u have a UI u'll want to run your main work in a different thread than in the event dispatcher thread as that will speed things up with the GUI.
now let's say we have the following code:
//Thread to prevent blocking and return control to GUI
Runnable r = new Runnable() {
public void run() {
try
ThreadThatDoesAlotOfWork.start();
} catch (Exception e)
e.printStackTrace();
if I'll run it within a another thread within the GUI, howcome it doesn't block till all work is done?
could u provide some code for blocking/non blocking threads..
can u direct me maybe to helpfull docs somewhere..
Thanks for the help and hope I'm being clear with my question..

That article is about synchronisation access to variables by mutiple threads.
I'm talking about using Threads for speeding things up...
Thanks for the reply anyway..

Client threads block forever in SSLSocketImpl.startHandshake

Hi --
We have an application which has 4 threads polling a webservice over HTTPS every 1-2 minutes. We don't control the server platform or webservice framework.
We've encountered a problem where one by one the threads stop polling. This has occurred 3 times, every time over a weekend (the busiest time for our polling). Each thread "freezes" at a different time; all 4 threads are "frozen" after about 24 hours.
JVM thread dumps suggests that the polling threads are blocked inside SSLSocketImpl.startHandshake; each one always has the same stacktrace within the JSSE & Axis libraries:
"SOAP Client Thread: Footy Feed" prio=5 tid=0x2877D388 nid=0x518 runnable [2c3af000..2c3afd8c]
     at java.net.SocketInputStream.socketRead0(Native Method)
     at java.net.SocketInputStream.read(SocketInputStream.java:129)
     at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA6275)
     at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA6275)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
     - locked <0A931078> (a java.lang.Object)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
     - locked <0A931068> (a java.lang.Object)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275)
     at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)
     at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:131)
     at org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:370)
     at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:88)
     at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
     at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
     at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
     at org.apache.axis.client.AxisClient.invoke(AxisClient.java:147)
     at org.apache.axis.client.Call.invokeEngine(Call.java:2719)
     at org.apache.axis.client.Call.invoke(Call.java:2702)
     at org.apache.axis.client.Call.invoke(Call.java:2378)
     at org.apache.axis.client.Call.invoke(Call.java:2301)
     at org.apache.axis.client.Call.invoke(Call.java:1758)
...(our application stacktrace)...
Client: JDK1.4.1-b21, JBoss 3.2.7RC1, Axis 1.2RC2, Win2k Server SP4, no client certificates
Server: Apache 1.3.29 (Unix) mod_ssl 2.8.16 OpenSSL 0.9.6j, mod_jk to Tomcat.
There's at least one firewall between client and server.
This problem appears similar: <http://issues.apache.org/bugzilla/show_bug.cgi?id=31832> & I've emailed the author.
I've googled a lot of forums for a solution without success.
Any help gratefully received.
Thanks
-- Richard Barnett

Thanks for the reply.
This case is different from that JMeter bug report as it's a SOAP request.
We're not explicitly setting a timeout, but Axis defaults to a 10 minute timeout on its requests. The source seems to indicate that this doesn't apply when creating SSL sockets (although it is used when creating regular sockets). No timeout occurs in any case.
-- Richard

OSB Service Callouts - HTTP Threads

Hi All,
We are having issues with OSB service callouts calling the business services from the Proxy Services. Due to excessive usage of Service Callouts, the proxy services are hanging out in the OSB server. From the Proxy services,we could able to successfully invoke the business services ( SOA Composistes , EJB Webservices etc ) and the webservices are taking few milliseconds to process the requests,but the response is not reaching the OSB Proxy Service. Ideally the behaviour is not happening for all requests, but for few messages. We have set up a dedicated Worker manager ( 10 Min Threads ) in the Admin Console and mapped the Worker manager to the business services ( dispatch policy ),but with no luck. We have followed the below link and its not working.
http://allthingsmdw.blogspot.co.uk/2012/09/osb-service-callouts-and-oql-part-3.html
Request to help us incase if you happen to see this behavior earlier.
Thanks,
Phani

Hi Phani,
It is a known issue with ALSB/OSB. There is a documentation in oracle as well regarding that "ALSB/OSB - Proxy Service Callout Causes Stuck Threads Under High Load [ID 861724.1]".
Symptoms
Stuck threads when calling a proxy service with a service callout /publish under high load. Proxy services using only ROUTE work without problems.
Cause
The service callout instantiates a new thread.
As the proxy services are running in the default thread pool there will be no thread available for the callout under high load because all threads are blocked by the proxy services waiting for the response.
This is expected behavior when using a service callout action and can be resolved by correct thread tuning.
Solution
A separate Workmanager needs to be configured for the Proxy service. This can be done by using the Dispatch Policy for specific proxy services (JMS, WS ..).
For detailed information go to the OSB transport specific documentation and look for Dispatch Policy.
There you will also see the link to the WLS Workmanager documentation.
Please create a Workmanager using <max-threads-constraint> to limit the number of parallel executing proxies.
Using this configuration the proxy will not block threads in the default queue.
The service callout will still use the threads from the default thread pool.
Hope this helps.
Regards,
Karan
http://learn-oraclesoa.blogspot.com/

Archiver Issue| Automatic replication process | Archiver thread blocking

Hi,
Recently, we are facing a strange issue with Archiver auto replication process. Sometime, archiver thread is blocking and auto replication is stalling. We observed this issue after we apply latest OUCM patches downloded from Oracle support site.
As an work around, we are doing UCM restart.
Anybody got this kind off issue? We are following this up with Oracle in parallel. Any help regarding this is highly appreciated.
Gowtham J

What version/patch set/core update of UCM are you using?
Jonathan
http://redstonecontentsolutions.com
http://corecontentonly.com

Future.get and the event despatch thread blocking

neeeyaaarghhhh
been tying myself in knots thinking about this
Following one of the java tech tips I've been using Callable and Future objects when I want to return a result from a task, in my case it's usually some file processing
So I have a file chooser gui, I select a file and launch my Callable and await the result in Future.get...
Now the problem is... Future.get I understand blocks the calling thread until the computation / work in the Callable is done and the result returned. In this case the blocked thread will be the event despatch thread... which causes problems as during my file reading I have a JProgressBar running and updating. Well at least I did, now it doesn't show up at all as all the updates to the JProgressBar via invokeLater are queued (as event despatch thread is blocked) until after the work thread has finished
How do I launch a Callable, await the result and have some limited gui activity as the task progresses? The only solution I've found is to have the ProgressBar in a modal dialog, to block out the rest of the gui like this whilst I do the work in the event despatch thread (and drop the idea of threading altogether)
Is my mental modal of how worker threads should spin off from the event thread flawed or am I just missing some 1 line command?

In the situation of updating the gui, you usually want to pass some sort of callback object to the asynchronous code and have that callback method run on the gui event thread.
public class GuiClass {
public void handleResult(Object data);
public void startTask() {
threadpool.execute(new Runnable() {
    public void run() {
      // ... do asynch work ...
      final Object myResult = ...;
      SwingUtilities.invokeLater(new Runnable() {
        public void run() {
          handleResult(myResult);
}In this code, the startTask method is called on the gui thread. it starts some async work on the threadpool. when finished, the asynch task queues the result to be handled back on the gui thread. the handleResult method is called later on the gui thread with the final result. thus, no blocking of the gui thread.
The Callable interface is great for when the invoking thread needs to wait for a result, but you pretty much never want to do this with the gui thread.

HTTP thread blocking

Similar Messages

Maybe you are looking for