Cari Blog Ini

Diberdayakan oleh Blogger.
Senin, 29 September 2008

Hung Threads with BO SDK - Solution

Hung Threads with BO SDK - Solution - welcome to the blog Software Gadget the end of this much calm product information launcing, yes every day there are always products that are removed from various brands, both physical hardware products and software that need new knowledge to use it, well now we will discuss first about Hung Threads with BO SDK - Solution as you search we have collected a lot of data to make this information as complete as possible for you, please read:

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.



so much information Hung Threads with BO SDK - Solution

hopefully the information Hung Threads with BO SDK - Solution that we provide can be useful for you in the set of technology products that fit your daily needs,

have just read the article titled Hung Threads with BO SDK - Solution if you feel useful information and you want to bookmark or share please use the link https://ramblingsofker.blogspot.com/2008/09/hung-threads-with-bo-sdk-solution.html and do not forget to go back to this blog if you want to know information about the latest gadgets.

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

Related : Hung Threads with BO SDK - Solution

0 komentar:

Posting Komentar