Techno Specs Gadget, Samsung Galaxy, New IMEI, Octopus Box Samsung, Android Jelly Bean, Ulefone Tiger, Chinese Miracle

Senin, 29 September 2008

Hung Threads with BO SDK - Solution

Hung Threads with BO SDK - Solution - are you surfing on google and finding this blog Techno Specs Gadget ?.. if yes, congratulations you will get updated information about Hung Threads with BO SDK - Solution we have collected a lot of information from various reliable sources to make this article, so make sure you read through to finish, please see.

Articles : Hung Threads with BO SDK - Solution
full Link : Hung Threads with BO SDK - Solution

You can also see our article on:


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 about Hung Threads with BO SDK - Solution has been completed in the discussion

hopefully the information Hung Threads with BO SDK - Solution that we provide can provide benefits for you in finding the information you need

you have finished reading the article about Hung Threads with BO SDK - Solution if you want to bookmark or also want to share this information to many people can use the link http://belialslut.blogspot.com/2008/09/hung-threads-with-bo-sdk-solution.html ok so and thank you.

Tag :
Share on Facebook
Share on Twitter
Share on Google+
Tags :

Related : Hung Threads with BO SDK - Solution

0 komentar:

Posting Komentar