Hung Threads with BO SDK - Solution - welcome to our blog that presents the full content How Gadget, the discussion this time we're discussing that you find that Hung Threads with BO SDK - Solution, we have provided complete information with images that are easy to understand, the explanation is simple but complete, therefore please read until the end :)

This is about : Hung Threads with BO SDK - Solution
And this article : Hung Threads with BO SDK - Solution

Hung Threads with BO SDK - Solution

Many developers seem to be facing the dreaded 'Hung threads' issue when they you the BO SDK in their java applications.

The symptoms:
The issue usually manifests itself with a line in the SystemOut.log or equivalent reporting the following:
WSVR0605W: Thread "THREAD NAME : ID" (55c8824f) has been active for 600,112 milliseconds and may be hung. There are 1 threads in total in the server that may be hung.

If you do a thread dump in your App Server at this point, you will see something like so:

- waiting on <0x93d29020> (a java.lang.Object)
at java.lang.Object.wait(Object.java:429)
at com.crystaldecisions.thirdparty.com.ooc.OB.Downcall.waitUntilCompleted(Downcall.java:831)
- locked <0x93d29020> (a java.lang.Object)
at com.crystaldecisions.thirdparty.com.ooc.OB.GIOPClientWorkerThreaded.receive(GIOPClientWorkerThreaded.java:327)
at com.crystaldecisions.thirdparty.com.ooc.OB.GIOPClientWorkerThreaded.sendReceive(GIOPClientWorkerThreaded.java:353)
at com.crystaldecisions.thirdparty.com.ooc.OB.Downcall.request(Downcall.java:336)
at com.crystaldecisions.thirdparty.com.ooc.OB.DowncallStub.invoke(DowncallStub.java:583)
at com.crystaldecisions.thirdparty.com.ooc.CORBA.Delegate.invoke(Delegate.java:579)
at com.crystaldecisions.thirdparty.org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:125)
at com.crystaldecisions.enterprise.ocaframework.idl.OCA.OCAi._InfoStoreEx3Stub.queryEx3(_InfoStoreEx3Stub.java:62)
at com.crystaldecisions.enterprise.ocaframework.j.a(Unknown Source)
at com.crystaldecisions.enterprise.ocaframework.j.find(Unknown Source)
at com.crystaldecisions.enterprise.ocaframework.AbstractServerHandler.buildServerInfo(Unknown Source)
at com.crystaldecisions.enterprise.ocaframework.AbstractServerHandler.buildClusterInfo(Unknown Source)
at com.crystaldecisions.enterprise.ocaframework.aa.for(Unknown Source)
at com.crystaldecisions.enterprise.ocaframework.ServiceMgr.for(Unknown Source)
at com.crystaldecisions.enterprise.ocaframework.o.a(Unknown Source)
at com.crystaldecisions.enterprise.ocaframework.o.a(Unknown Source)
at com.crystaldecisions.enterprise.ocaframework.o.a(Unknown Source)
at com.crystaldecisions.enterprise.ocaframework.p.a(Unknown Source)
at com.crystaldecisions.enterprise.ocaframework.ServiceMgr.getManagedService(Unknown Source)
at com.crystaldecisions.sdk.occa.managedreports.ras.internal.CECORBACommunicationAdapter.connect(Unknown Source)
at com.crystaldecisions.sdk.occa.managedreports.ras.internal.RASReportAppFactory.a(Unknown Source)
at com.crystaldecisions.sdk.occa.managedreports.ras.internal.RASReportAppFactory.a(Unknown Source)
at com.crystaldecisions.sdk.occa.managedreports.ras.internal.RASReportAppFactory.openDocument(Unknown Source)
at com.crystaldecisions.sdk.occa.managedreports.ras.internal.RASReportAppFactory.openDocument(Unknown Source)
at com.talic.pi.utils.ReportingEngine.generateReport(ReportingEngine.java:86)
at com.talic.pi.cms.dao.ReportsDAO.generateReport(ReportsDAO.java:31)
at com.talic.pi.cms.component.ReportGeneratorComponentImpl.generateReport(ReportGeneratorComponentImpl.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.ibm.ws.sca.internal.java.handler.JavaReflectionAdapter$2.run(JavaReflectionAdapter.java:152)

The cause:
This is mainly caused by reports that take a great deal of time to execute causing the application server to report that the processing thread is 'hung'. A worse side effect of this is when the application server runs out of threads and is unable to process any further requests due to these hung threads.

The solution:
The problem is due to the fact that the Corba Timeout has not been set. You've missed the clientSDKOptions.xml in your deployment. This causes the RAS SDK to probably never timeout its call to the RAS.

Create a file called clientSDKOptions.xml and place it in your application's WEB-INF/classes folder, or alternatively, you could place it in a server wide classpath folder like 'applib' on OC4J or $WASPROFILE/properties on WebSphere.
The contents of the file should be as follows:


<CrystalReports.ClientSDKOptions
 xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
 version="2"
 xsi:type="CrystalReports.ClientSDKOptions">
   <CORBARequestTimeout>120000</CORBARequestTimeout>
</CrystalReports.ClientSDKOptions>

Restart your app and your done. Your call should now timeout within 2 minutes (something with you can change) and you can say goodbye to your Hung Threads issue.

Information Hung Threads with BO SDK - Solution has been completed we present

A few of our information about the Hung Threads with BO SDK - Solution, we hope you benefit from this article

You have just read the article Hung Threads with BO SDK - Solution and many articles about gadget in our blog this, please read it. and url link of this article is https://howtomonetizeeverything.blogspot.com/2008/09/hung-threads-with-bo-sdk-solution.html Hopefully discussion articles on provide more knowledge about the world of tech gadgets.

Tag :