ExecuteThread for queue: 'weblogic.kernel.Default' stuck

Hello!
I have web application deployed on WebLogic 8.1 SP 4 cluster which is seriously loaded (~30 concurrent users) and periodically I get such messages wrote to log file:
<Apr 2, 2007 10:11:54 AM EDT> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '51' for queue: 'weblogic.kernel.Default' has been busy for "233" seconds working on the request "Http Request: /myurl/some_jsp.jsp", which is more than the configured time (StuckThreadMaxTime) of "180" seconds.>
As far as I could find from BEA documentation these messages mean that some threads (it is ExecuteThread#51 here) are runned for too long time.
I've made a thread dump and found that for a few (10-15min) thread is doing the same work:
"ExecuteThread: '51' for queue: 'weblogic.kernel.Default'" daemon prio=1 tid=0x6ca004b8 nid=0x3094 runnable [0x6c9fe000..0x6c9ff868]
     at java.net.SocketOutputStream.socketWrite0(Native Method)
     at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
     at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
     at weblogic.servlet.internal.ChunkUtils.writeChunkNoTransfer(ChunkUtils.java:280)
     at weblogic.servlet.internal.ChunkUtils.writeChunks(ChunkUtils.java:241)
     at weblogic.servlet.internal.ChunkOutput.flush(ChunkOutput.java:311)
     at weblogic.servlet.internal.ChunkOutput.checkForFlush(ChunkOutput.java:387)
     at weblogic.servlet.internal.ChunkOutput.write(ChunkOutput.java:254)
     at weblogic.servlet.internal.MultibyteOutput.write(ChunkOutput.java:482)
     at weblogic.servlet.internal.ChunkOutputWrapper.write(ChunkOutputWrapper.java:125)
     at weblogic.servlet.jsp.JspWriterImpl.write(JspWriterImpl.java:455)
As you can see, thread is just writing to the socket for 10-15 minutes!!!
Can you help with some suggestions? Can this problem occure because of huge overloading to the server?
Thanks for all your responses.
Thanks

I have installed the Spring application on WebLogic 8.1 SP4 on Red HAt Linux 3.0.
These message doesn't appear for WebLogic 8.1 SP4 on windows.
2007-05-10 10:22:50,356 [l.Default'] DEBUG org.springframework.web.servlet.DispatcherServlet: Rendering view [org.springframework.web.servlet.view.JstlView: unnamed; URL [/util/noAccess.jsp]] in DispatcherServlet with name 'spring'
2007-05-10 10:22:50,376 [l.Default'] DEBUG org.springframework.web.servlet.DispatcherServlet: Could not complete request
java.net.SocketException: Connection reset
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:96)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at weblogic.servlet.internal.ChunkUtils.writeChunkTransfer(ChunkUtils.java:267)
at weblogic.servlet.internal.ChunkUtils.writeChunks(ChunkUtils.java:239)
at weblogic.servlet.internal.ChunkOutput.flush(ChunkOutput.java:311)
at weblogic.servlet.internal.ChunkOutput.checkForFlush(ChunkOutput.java:387)
at weblogic.servlet.internal.ChunkOutput.write(ChunkOutput.java:254)
at weblogic.servlet.internal.ChunkOutputWrapper.write(ChunkOutputWrapper.java:125)
at weblogic.servlet.jsp.JspWriterImpl.write(JspWriterImpl.java:455)
at jsp_servlet._util.__noaccess._writeText(__noaccess.java:74)
at jsp_servlet._util.__noaccess._jspService(__noaccess.java:283)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1006)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:315)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:322)
at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:111)
at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:965)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:744)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:663)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1006)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:315)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:322)
at weblogic.servlet.internal.ServletResponseImpl.sendError(ServletResponseImpl.java:531)
at weblogic.servlet.internal.ServletResponseImpl.sendError(ServletResponseImpl.java:383)
at weblogic.servlet.FileServlet.findSource(FileServlet.java:281)
at weblogic.servlet.FileServlet.service(FileServlet.java:184)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1006)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:315)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6718)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3764)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2644)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)

Similar Messages

WebLogicServer BEA-000337 ExecuteThread: '11' for queue: 'weblogic.kernel.Default' has been busy for "698" seconds working on the request

Hi,
When I invoke this JSP, the servlet gets the request and sends a reply, but the
JSP never finishes. The connection isn't dropped, the browser icon keeps spinning,
as if it is still trying to load the page. But nothing ever happens. After more
than 10 minutes or more I get a message in the stdout of weblogic server saying
something about a stuck thread.
Note: The JSP sends an SQL statement to Servlet, which in turn calls a DAO class
to execute the sql and return the result back to Servlet. i m using Weblogic 8.1
Please help me as it is very urgent. Production Problem. It occurs randomly.

Hi,
It looks like you have an AXIS webservice based Application deployed on the Server which has the following Method: com.test.ws.Stub.getInfo(ClientStub.java:813) the call to that method is happening over HTTPS protocol. getInfo() method might be trying to read a Large amount of Information from some sources which may be taking more than 600 Seconds. 600 Seconds is the Default Duration for WebLogic Threads after which the WebLogic Marks those Threads as Stuck Thread.
So we need to debug the data which is being fetch by the Application code at the following line com.test.ws.Stub.getInfo(ClientStub.java:813)...It might be possible that sometimes while execution of the above method it might be processing or asking for a Large amount of Data which is more than the Configured Thread Timeout period.
As well as it looks like the Above code is trying to get some data from a remote Server/JVM beacuse it is getting stuck while reading Data from a Socket:
java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.read(SocketInputStream.java:129)
So u need to check the Other end also from where the code is actually trying to get the Information or Data ....*com.test.ws.Stub.getInfo(ClientStub.java:813)*
Developers can easily findout what the "ClientStub.java" classes method getInfo() is actually doing.
Thanks
Jay SenSharma
http://middlewaremagic.com/weblogic/?page_id=2261 (Middleware Magic Is Here)

Weblogic.kernel.Default Queue problems

Hello,
We have a problem with our Production server where the threads in the weblogic.kernel.Default queue simply hang up .
The Stuck Thread Max Time and the Stuck Thread Timer Interval have been configured for 60s but many times the threads simply dont get UnStuck. :(
Is there anyway to kill the threads without restarting the Server itself ???
thanks,
sg

We generated varios thread dumps and we found a number of threads in "locked" state with LDAP :
"ExecuteThread: '15' for queue: 'weblogic.kernel.Default'" daemon pri
     at java.lang.Object.wait(Native Method)
     - waiting on <73e5b9d0> (a com.sun.jndi.ldap.LdapRequest)
     at com.sun.jndi.ldap.Connection.readReply(Connection.java:418)
     - locked <73e5b9d0> (a com.sun.jndi.ldap.LdapRequest)
     at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:701)
The thing is, there is nothing wrong with LDAP. We are simulating new requests to LDAP and LDAP is responding is less than 1 s ! But the thread dump indicates the threads are hung in LDAP :(
The LDAP admin did a thorough check and came up with nothing... Is there anything else I can check for ?
thnx,
sg

How to get rid of the weblogic.kernel.Default errors and warning?

Hi there,
When i'm running my application deployed on WLS8.1 SP3 and the application is running fine, but the following error and warnings were thrown.
2004-08-05 11:26:30,453 [ExecuteThread: '13' for queue: 'weblogic.kernel.Default'] ERROR com.bea.wlw.runtime.core.util.Config - Failed to obtain connection to datasource=cgDataSource, using generic DB properties
<Aug 5, 2004 11:26:30 AM SGT> <Error> <WLW> <000000> <Failed to obtain connection to datasource=cgDataSource, using generic DB properties>
2004-08-05 11:27:12,281 [ExecuteThread: '13' for queue: 'weblogic.kernel.Default'] WARN org.apache.jcs.config.OptionConverter - Could not find value for key jcs.default.elementattributes
2004-08-05 11:27:12,282 [ExecuteThread: '13' for queue: 'weblogic.kernel.Default'] WARN org.apache.jcs.engine.control.CompositeCacheConfigurator - Could not instantiate eAttr named 'jcs.default.elementattributes', using defaults.
2004-08-05 11:27:12,308 [ExecuteThread: '13' for queue: 'weblogic.kernel.Default'] WARN org.apache.jcs.config.OptionConverter - Could not find value for key jcs.system.groupIdCache.elementattributes
2004-08-05 11:27:12,308 [ExecuteThread: '13' for queue: 'weblogic.kernel.Default'] WARN org.apache.jcs.engine.control.CompositeCacheConfigurator - Could not instantiate eAttr named 'jcs.system.groupIdCache.elementattributes', using defaults.
2004-08-05 11:27:12,386 [ExecuteThread: '13' for queue: 'weblogic.kernel.Default'] WARN org.apache.jcs.config.OptionConverter - Could not find value for key jcs.region.CodeTableCache.elementattributes
2004-08-05 11:27:12,386 [ExecuteThread: '13' for queue: 'weblogic.kernel.Default'] WARN org.apache.jcs.engine.control.CompositeCacheConfigurator - Could not instantiate eAttr named 'jcs.region.CodeTableCache.elementattributes', using defaults.
2004-08-05 11:27:13,527 [ExecuteThread: '13' for queue: 'weblogic.kernel.Default'] WARN com.bea.wlw.netui.script.el.NetUIReadVariableResolver - Could not create a ContextFactory for type "com.bea.netuix.servlets.script.PortalVariableResolver$PortalContextFactory" because the ContextFactory implementation class could not be found.
May i know why this is so? How to get rid of these error and warnings?
Thanks
Derek
Message was edited by derekchan at Aug 4, 2004 8:41 PM
Message was edited by derekchan at Aug 4, 2004 8:42 PM

you didnt seem to have configured the datasource / connection pool / database control with proper db properties
you should check your configuration to see if you have done it right and then you should check your application and the properties settings in the controls to ensure they are right.

Weblogic.kernel.Default not using all threads

We are running weblogic 8.1 sp4 on HP Tru64 5.1.
We have an admin server and 3 managed servers in a cluster.
When monitoring the weblogic.kernal.Default execute threads through the weblogic console, threads 0 to 15 have zero total requests, and the user is marked '<WLS Kernal>'. Threads 16 to 24 share the entire workload with thousands of requests shared between them, and have user marked as 'n/a' (when idle).
I have done a thread dump, and threads 0 to 15 just seem to be idle.
This is the case for the admin server, server 1 and server 3. But server 2 actually shows all threads 0 to 24 as sharing the workload, and the user is 'n/a' for all threads.
Is there a reason for this?
Below is a snippet of the thread dump showing a thread that is has user '<WLS Kernel>':
**** ExecuteThread: '3' for queue: 'weblogic.kernel.Default' thread 0x207d8e80 Stack trace:
pc 0x03ff805c2cc8 sp 0x200026ecc00 __hstTransferRegisters (line -1)
pc 0x03ff805b2384 sp 0x200026ecc00 __osTransferContext (line -1)
pc 0x03ff805a3d20 sp 0x200026ecd90 __dspDispatch (line -1)
pc 0x03ff805a309c sp 0x200026ecde0 __cvWaitPrim (line -1)
pc 0x03ff805a0518 sp 0x200026ece80 __pthread_cond_wait (line -1)
pc 0x03ffbff31558 sp 0x200026ecea0 monitor_wait (line 625)
pc 0x03ffbff5ea48 sp 0x200026ecf10 JVM_MonitorWait (line 1037)
pc 0x00003001304c sp 0x200026ecf20 -1: java/lang/Object.wait(J)V
pc 0x0000302047dc sp 0x200026ecfd0 2: java/lang/Object.wait()V
pc 0x000030204784 sp 0x200026ecfe0 8: weblogic/kernel/ExecuteThread.waitForRequest()V
pc 0x0000302044ec sp 0x200026ed000 43: weblogic/kernel/ExecuteThread.run()V
pc 0x03ffbff91b28 sp 0x200026ed030 unpack_and_call (line 100)
pc 0x03ffbff89ca4 sp 0x200026ed040 make_native_call (line 331)
pc 0x03ffbff27bb0 sp 0x200026ed0f0 interpret (line 368)
pc 0x03ffbff36bf0 sp 0x200026ed9d0 jni_call (line 583)
pc 0x03ffbff378d8 sp 0x200026eda60 jni_CallVoidMethodA (line 70)
pc 0x03ffbff37980 sp 0x200026eda90 jni_CallVoidMethod (line 88)
pc 0x03ffbff2ecf4 sp 0x200026edb10 java_thread_start (line 592)
pc 0x03ffbff2e720 sp 0x200026edb30 thread_body (line 460)
pc 0x03ff805cf278 sp 0x200026edc00 __thdBase (line -1)

Grand central dispatch - infancy, not really doing its job, and I don't think apps have to be specifically written for HT, but they do have to not do things that they use to - prevent threads from going to sleep! or be parked.
high usage is not necessarily high efficiency. often the opposite.
Windows 7 seems to be optimized for multi-core thanks to a lot of reworking. Intel wants and knows it isn't possible to hand code, that the hardware has to be smarter, too. But the OS has a job, and right now I don't think it does it properly. Or handle memory.
Gulftown's 12MB cache will help, and over all should be 20% more efficient doing its work.
With dual processors, and it doesn't look like there are two quick path bridges, data shuffling has led to memory thrashing. Use to be page thrashing with not enough memory. Then core thrashing but having the cores, but not integrated (2008 is often touted as being greatest design so far, but it was FOUR dual-cores, 2009 was the first with a processor that really was new design and (native) 4-core.
One core should be owned by the OS so it is always available for its own work and housekeeping.
The iTunes audio bug last year showed how damaging and not to implement code and how a thread could usurp processing and add a high cpu temperature while basically doing nothing, sort of a denial of service attack on the processor - those 80*C temps people had.
All those new technology features under development and not like OpenCL, GCD and even OpenGL are tested, mature but rather 1.0 foundation for the future. A year ahead of readiness.

Weblogic.kernel.Default' has become "unstuck"

Running WL 8.1 sp2 on Windows XP Pro. with 2Gb. of memory.
I have an EJB 2.0 CMP application accessing an Oracle 8.1.7 database.
I retrieve 1,440 rows and then start processing each row, and submitt "Jobs" to
a third party product using WebServices.
It only had 3 rows remaining to process when I got;
<03-Feb-2004 13:45:47 o'clock GMT> <Info> <WebLogicServer> <BEA-000339> <ExecuteThread:
'10' for queue: 'weblogic.kernel.Default' has become "unstuck".>
Any pointers?
Thanks.

增大JVM堆栈，如果不行的话打开GC详细输出看看

Why are the weblogic.kernel.Default Execute Threads used by WLS Kernel

In my Admin Console, it's displaying 10 out of the 15 weblogic.kernel.Default Execute Threads are used by the WLS Kernel user. The total requests column for these threads are showing 0. The other 5 threads are showing 20K to 40K requests. Why is the WLS Kernel users hogging these threads and not allowing the applications to use them?

Hi,
As work enters a WebLogic Server, it is placed in an execute queue. This work is then assigned to a thread within the queue that performs the work.
By default, a new server instance is configured with a default execute queue, weblogic.kernel.default, that contains 15 threads.
Go through the following link and find the usefull information on this issue.
http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_executequeuetable.html
Regards
Anilkumar kari

Weblogic.kernel.Default

I have two servers, serverOne and serverTwo, that are running different applications on WL815, Solaris 10, x86 platform.
Both have ThreadCount=25, Threads Max=400, and Threads Increase = 15.
1. I have noticed when I monitor the weblogic.kernel.Default queue, no matter how much the load is on the server, there are no more than 25 thread in the queue. Why is it?
2. On serverOne, only 6 threads out of the 25 are being used by <WLS Kernel> and the rest of the threads are allocated to the applications. However, on serverTwo, about 19 threads out of 25 are being used by <WLS Kernel>, and ther rest are used by the application. FYI, there are 4 application queues deployed on serverTwo. What is the reason for so many threads being used by <WLS Kernel> on ServerTwo?
Thanks for all your answers in advance!

Can you post the complete stacktrace? That may yield a clue.

How does WebLogic clean up stuck threads?

Hi,
Using WebLogic 9.2.2 on Linux OS. In our logs, we are finding some stuck threads and it seems to be due to something WebLogic is doing. While we don't understand the cause (maybe the stack trace helps), does WebLogic do anything to remove stuck threads from its pool, or is there anything we can do to configure it to?
<Jul 21, 2009 2:50:21 PM UTC> <Error> <WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "605" seconds working on the request "Http Request: /RoutingEngine/pcFlow.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
Thread-69 "[STUCK] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'" <alive, in native, suspended, priority=1, DAEMON> {
jrockit.net.SocketNativeIO.readBytesPinned(Unknown Source)
jrockit.net.SocketNativeIO.socketRead(Unknown Source)
java.net.SocketInputStream.socketRead0(SocketInputStream.java:???)
java.net.SocketInputStream.read(SocketInputStream.java:107)
java.io.BufferedInputStream.fill(BufferedInputStream.java:189)
java.io.BufferedInputStream.read(BufferedInputStream.java:234)
^-- Holding lock: java.io.BufferedInputStream@3537712[thin lock]
weblogic.net.http.MessageHeader.isHTTP(MessageHeader.java:214)
weblogic.net.http.MessageHeader.parseHeader(MessageHeader.java:141)
weblogic.net.http.HttpClient.parseHTTP(HttpClient.java:473)
^-- Holding lock: java.io.BufferedInputStream@3537712[thin lock]
weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:332)
^-- Holding lock: java.io.BufferedInputStream@3537712[thin lock]
weblogic.net.http.SOAPHttpURLConnection.getInputStream(SOAPHttpURLConnection.java:36)
weblogic.wsee.util.dom.DOMParser.getWebLogicDocumentImpl(DOMParser.java:92)
weblogic.wsee.util.dom.DOMParser.getDocument(DOMParser.java:56)
weblogic.wsee.wsdl.WsdlReader.getDocument(WsdlReader.java:311)
weblogic.wsee.wsdl.WsdlReader.getDocument(WsdlReader.java:305)
weblogic.wsee.wsdl.WsdlSchema.parse(WsdlSchema.java:120)
weblogic.wsee.wsdl.WsdlSchemaImport.parse(WsdlSchemaImport.java:55)
weblogic.wsee.wsdl.WsdlSchema.parse(WsdlSchema.java:82)
weblogic.wsee.wsdl.WsdlSchema.parse(WsdlSchema.java:62)
weblogic.wsee.wsdl.WsdlTypes.parse(WsdlTypes.java:145)
weblogic.wsee.wsdl.WsdlDefinitions.parseChild(WsdlDefinitions.java:452)
weblogic.wsee.wsdl.WsdlExtensible.parse(WsdlExtensible.java:84)
weblogic.wsee.wsdl.WsdlDefinitions.parse(WsdlDefinitions.java:378)
weblogic.wsee.wsdl.WsdlDefinitions.parse(WsdlDefinitions.java:358)
weblogic.wsee.wsdl.WsdlFactory.parse(WsdlFactory.java:50)
weblogic.wsee.jaxrpc.ServiceImpl.loadWsdlDefinition(ServiceImpl.java:437)
weblogic.wsee.jaxrpc.ServiceImpl.<init>(ServiceImpl.java:95)
com.myco.regui.provisioning.client.ProvisioningAccountService_Impl.<init>(ProvisioningAccountService_Impl.java:21)
com.myco.regui.provisioning.client.ProvisioningAccountService_Impl.<init>(ProvisioningAccountService_Impl.java:17)
com.myco.regui.struts.accounts.AccountsForm.contactWPS(AccountsForm.java:208)
com.myco.regui.struts.accounts.AccountsForm.validateAccountid(AccountsForm.java:161)
com.myco.regui.struts.accounts.AccountsForm.validatePCAccountId(AccountsForm.java:144)
com.myco.regui.struts.accounts.AccountsForm._validatePCFields(AccountsForm.java:112)
com.myco.regui.struts.accounts.AccountsForm.validate(AccountsForm.java:83)
org.apache.struts.chain.commands.servlet.ValidateActionForm.validate(ValidateActionForm.java:57)
org.apache.struts.chain.commands.AbstractValidateActionForm.execute(AbstractValidateActionForm.java:94)
org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:48)
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:176)
org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:303)
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:176)
org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:272)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1903)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462)
javax.servlet.http.HttpServlet.service(HttpServlet.java:736)
javax.servlet.http.HttpServlet.service(HttpServlet.java:851)
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:224)
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:108)
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:198)
weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:41)
com.myco.regui.servlets.filters.TransactionFilter.doFilter(TransactionFilter.java:23)
.......

You can configure these actions to occur when not all threads are stuck, but the number of stuck threads have exceeded a configured threshold:
* Shut down the Work Manager if it has stuck threads. A Work Manager that is shut down will refuse new work and reject existing work in
the queue by sending a rejection message. In a cluster, clustered clients will fail over to another cluster member.
* Shut down the application if there are stuck threads in the application. The application is shutdown by bringing it into admin mode. All
Work Managers belonging to the application are shut down, and behave as described above.
* Mark the server instance as failed and shut it down it down if there are stuck threads in the server. In a cluster, clustered clients that
are connected or attempting to connect will fail over to another cluster member.
Link : [http://e-docs.bea.com/wls/docs103/config_wls/overload.html]

Weblogic threads getting stuck at setAutoCommit

Hi,
We are using Weblogic 10.3.4 in our production environment with Oracle 11g backend.
Yesterday two of the transactions timed-out as the threads running these transactions blocked at the setAutoCommit method. Upon checking the de-compiled classes in ojdbc.jar, the threads seem to try obtaining a lock to execute the synchronized method doSetAutoCommit in T4CConnection class.
There were no other transactions running at the time the thread dump was taken. What could be be reason for two threads to block at the same method while no other thread seems to hold the lock?
Please find the stack traces from the thread dump below. Both the threads were running the same application transaction (perhaps 2 users initiated the transaction or the same user tried the transaction twice).
"[STUCK] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'" waiting for lock oracle.jdbc.driver.T4CConnection@ee159e BLOCKED
     oracle.jdbc.driver.PhysicalConnection.setAutoCommit(PhysicalConnection.java:3735)
     oracle.jdbc.OracleConnectionWrapper.setAutoCommit(OracleConnectionWrapper.java:130)
     weblogic.jdbc.wrapper.XAConnection.setAutoCommit(XAConnection.java:833)
     weblogic.jdbc.wrapper.JTAConnection.recoverAutoCommitState(JTAConnection.java:237)
     weblogic.jdbc.wrapper.JTAConnection.getXAConn(JTAConnection.java:222)
     weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:74)
     weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:65)
     weblogic.jdbc.wrapper.Statement.checkStatement(Statement.java:315)
     weblogic.jdbc.wrapper.Statement.doClose(Statement.java:411)
     weblogic.jdbc.wrapper.Statement.close(Statement.java:398)
"[STUCK] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'" waiting for lock oracle.jdbc.driver.T4CConnection@1d67b41 BLOCKED
     oracle.jdbc.driver.PhysicalConnection.setAutoCommit(PhysicalConnection.java:3735)
     oracle.jdbc.OracleConnectionWrapper.setAutoCommit(OracleConnectionWrapper.java:130)
     weblogic.jdbc.wrapper.XAConnection.setAutoCommit(XAConnection.java:833)
     weblogic.jdbc.wrapper.JTAConnection.recoverAutoCommitState(JTAConnection.java:237)
     weblogic.jdbc.wrapper.JTAConnection.getXAConn(JTAConnection.java:222)
     weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:74)
     weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:65)
     weblogic.jdbc.wrapper.Statement.checkStatement(Statement.java:315)
     weblogic.jdbc.wrapper.Statement.doClose(Statement.java:411)
     weblogic.jdbc.wrapper.Statement.close(Statement.java:398)

I'd like to see the full stacktraces. It is an error to have two application threads operating on the
same JDBC connection or any of it's subobjects, or operating on behalf of the same global
transaction.

Weblogic 8.14: Stuck Threads during JMS - IO native write operations

G'day!
Hope somebody can advise a solution on the following...
Recently message loads have started to increase on our weblogic 8.14 cluster (3 servers) and we started to see an almost daily occurrence of Stuck Thread issues. From thread dumps we could see these were caused by jrockit/net/SocketNativeIO.write processes. We concluded we had reached the max performance limit for the file based JMS stores and so we moved these to database based JMS stores. This certainly seemed to improve matters - but we have recently seen the issue return. Which is puzzling, as technically we thought all messages would be persisted to the database, and any file IO on the application server would be eliminated. Our database resides on a separate dedicated oracle server. We tracked a recent cause to a large message (200K) which caused the Struck Thread - resulting in a build up of pending messages. After bouncing the server the message processed ok. Any thoughts on how to overcome these issues - greatly appreciated. Here's some detail on the stuck thread from the thread dump: (+Why does weblogic use IO when the JMS store is on a database?+). All messages are persistant.
"ExecuteThread: '6' for queue: 'weblogic.kernel.Default'" prio=5 id=0xc00 pid=27544 active, daemon
at jrockit/net/SocketNativeIO.write(Native Method)@0xf3aeae10
at jrockit/net/SocketNativeIO.write(Unknown Source)@0xf3aeae9c
at jrockit/io/NativeIO.write(Unknown Source)@0xf3ae62c6
at java/net/AbstractSocketImpl$2.write(Unknown Source)@0xf3aeada4
at jrockit/io/NativeIOOutputStream.write(Unknown Source)@0xf3ae61ec
at jrockit/io/NativeIOOutputStream.write(Unknown Source)@0xf3ae618d
at java/io/DataOutputStream.write(Unknown Source)@0xf4e3ec25
^-- Holding lock: java/io/DataOutputStream@0x4309fc80[thin lock]
at com/ibm/mq/MQInternalCommunications.send(MQInternalCommunications.java:1022)@0xed34364a
^-- Holding lock: com/ibm/mq/MQInternalCommunications@0x4309f7e0[thin lock]
at com/ibm/mq/MQSESSIONClient.lowLevelComms(MQSESSIONClient.java:2832)@0xed342fbd
^-- Holding lock: java/lang/Integer@0x4309f8a0[thin lock]
at com/ibm/mq/MQSESSIONClient.MQPUT(MQSESSIONClient.java:3844)@0xed34271b
at com/ibm/mq/MQQueue.putMsg2(MQQueue.java:1486)@0xed342262
^-- Holding lock: com/ibm/mq/MQSPIQueue@0x4312ce80[thin lock]
at com/ibm/mq/jms/MQMessageProducer.sendInternal(MQMessageProducer.java:1569)@0xed33d1ab
at com/ibm/mq/jms/MQMessageProducer.send(MQMessageProducer.java:1012)@0xed860a49
at com/ibm/mq/jms/MQMessageProducer.send(MQMessageProducer.java:1046)@0xed8605f4
at weblogic/jms/adapter/JMSBaseConnection.sendInternal(JMSBaseConnection.java:667)@0xef7df0bf
^-- Holding lock: weblogic/jms/adapter/JMSBaseConnection@0x43093748[thin lock]
at weblogic/jms/adapter/JMSBaseConnection.access$200(JMSBaseConnection.java:80)@0xef7dee28
at weblogic/jms/adapter/JMSBaseConnection$6.run(JMSBaseConnection.java:647)@0xef7dee1d
at weblogic/security/acl/internal/AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)@0xf2fcbb88
at weblogic/security/service/SecurityManager.runAs(SecurityManager.java:147)@0xf2fcbb0a
at weblogic/jms/adapter/JMSBaseConnection.send(JMSBaseConnection.java:644)@0xef7decf3
at weblogic/jms/adapter/JMSConnectionHandle.send(JMSConnectionHandle.java:144)@0xef7dec7c
at jrockit/reflect/NativeMethodInvoker.invoke0(Native Method)@0xf4f10d10
at jrockit/reflect/NativeMethodInvoker.invoke(Unknown Source)@0xf4f10e98
at jrockit/reflect/VirtualNativeMethodInvoker.invoke(Unknown Source)@0xf4e86d70
at java/lang/reflect/Method.invoke(Unknown Source)@0xf4f104c3
at weblogic/connector/common/internal/ConnectionWrapper.invoke(ConnectionWrapper.java:149)@0xed96a498
at $Proxy14.send(Unknown Source)@0xef7dec04
at weblogic/jms/bridge/internal/MessagingBridge.onMessageInternal(MessagingBridge.java:1258)@0xed857b25
at weblogic/jms/bridge/internal/MessagingBridge.onMessage(MessagingBridge.java:1181)@0xed857864
at weblogic/jms/adapter/JMSBaseConnection$27.run(JMSBaseConnection.java:1943)@0xef7de623
at weblogic/security/acl/internal/AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)@0xf2fcbb88
at weblogic/security/service/SecurityManager.runAs(SecurityManager.java:147)@0xf2fcbb0a
at weblogic/jms/adapter/JMSBaseConnection.onMessage(JMSBaseConnection.java:1939)@0xef7de586
at weblogic/jms/client/JMSSession.onMessage(JMSSession.java:2678)@0xeee7e30c
at weblogic/jms/client/JMSSession.execute(JMSSession.java:2598)@0xeee7d25d
at weblogic/kernel/ExecuteThread.execute(ExecuteThread.java:219)@0xf4e14070
at weblogic/kernel/ExecuteThread.run(ExecuteThread.java:178)@0xf4e1fddb
at java/lang/Thread.startThreadFromVM(Unknown Source)@0xf4f3c9f3
Thanks
C.

I'm not sure what operating system you're running, but I only have experience of WLS8.1 on Windows.
We did extensive load testing of JMS before we went live, and found JDBC file stores to be rubbish in comparison to file store. When a message is persisted, it has to be written to the database, then when it is consumed, it must be deleted from the table. This simply killed our system when we load tested it.
One thing we did do though, was use a second JMS server and second file store for one particularly heavy queue, where we did have IO issues. This was with a JMS distributed destination. We also use a synchronous write policy of cache-flush on the file store and we also have configured a paging store to page messages so the app server does not run out of memory.
200K isn't by any means a huge message though, and shouldn't be any problem at all, we have 1mb messages quite regularly.
I notice from the stack trace, that you have MQ series aswell. I'm not experienced with MQ, so can't give any information, but what I would try is the following.
Using a JMS server with JMS File storage, develop a small java client to write as many messages to the queue and effectively stress the JMS subsystem just to establish if the filestore is the problem. This should be done without a connection to MQ and also use large messages. if you don't get any issues and WebLogic JMS with file store looks ok, then attach a consumer to the queue, which should also be a simple java client. Then you have production and consumption going on, which will result in writes and read's/deletes from the jms file store.
Once you've stress tested JMS and you are satisfied that its ok or not, then add the MQseries connection and see how that affects things.
You may well have already done all this, so please feel free to ignore me! I did a load of this kind of stuff before we went live to try and bash JMS to bits, but I didn't manage it! The only thing we did was add a second file store and second JMS server.
I just looked back in my support cases, and found we'd had a similar issue - disk fragmentation seemed to be one of the factors here too. The JMS file store was heavily fragmented. That's windows for you though!!!
Hope that helps.
Pete

Timeout waiting for Oracle WebLogic Server v10.3 at localhost to start

I am trying to run .portal file using "Run on server" option in Workshop for weblogic.
After doing this, its trying to start the server Oracle weblogic server v10.3 at localhost and then publish my module.
Server view status shows as "State" as "Starting" and "Status" as "Synchronizing". When status reaches 82% it gets stopped there for a long time, and when 83% comes up, I can see the "State" as "Stopped" and "Status" as "Republish". And then an error window with title as "Problem Occured" and contents saying, Starting server- Oracle weblogic server v10.3 at localhost (Time of error: ...) Details >> Timeout waiting for Oracle WebLogic Server v10.3 at localhost to start. Server did not start after 480s.
But the console tab (when I give the startup & Deployment option as "Launch Weblogic server in eclipse console) shows,
<Sep 8, 2011 6:15:03 PM IST> <Notice> <WebLogicServer> <BEA-000365> <Server sta
e changed to STARTING> (final step alone I pasted)
Before this I can see, WLS Start mode = Development, setting Classpath ,
<Sep 8, 2011 5:56:36 PM IST> <Notice> <Log Management> <BEA-170019> <The server
log file C:\bea\user_projects\domains\myPortalDomain\servers\AdminServer\logs\Ad
minServer.log is opened. All server side log events will be written to this file
.>
When I checked Adminserver file its having,
<AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1315487671986> <BEA-160151> <Registered library Extension-Name: wlp-groupspace-app-lib, Specification-Version: 10.3, Implementation-Version: 10.3.0.1 (EAR).>
And many more similar entries...
Also there is Adminserver.logxxx file which is having,
####<Sep 8, 2011 5:33:58 PM IST> <Warning> <JDBC> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1315483438048> <BEA-001129> <Received exception while creating connection for pool "portalDataSourceNeverXA": SQL-server rejected establishment of SQL-connection. Pointbase Server may not be running on localhost at port 9093.>
####<Sep 8, 2011 5:33:58 PM IST> <Info> <JDBC> <CINTNCHEOLY0GX7> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1315483438267> <BEA-001156> <Stack trace associated with message 001129 follows:
java.sql.SQLException: SQL-server rejected establishment of SQL-connection. Pointbase Server may not be running on localhost at port 9093.
     at com.pointbase.dbexcp.dbexcpException.getSQLException(Unknown Source)
     at com.pointbase.net.netJDBCConnection.a(Unknown Source)
     at com.pointbase.net.netJDBCConnection.<init>(Unknown Source)
     at com.pointbase.net.netJDBCDriver.getConnection(DashoA10*..:170)
     at com.pointbase.net.netJDBCDriver.connect(DashoA10*..:94)
     at com.pointbase.jdbc.jdbcUniversalDriver.getConnection(Unknown Source)
     at com.pointbase.jdbc.jdbcUniversalDriver.connect(Unknown Source)
     at weblogic.jdbc.common.internal.ConnectionEnvFactory.makeConnection(ConnectionEnvFactory.java:316)
     at weblogic.jdbc.common.internal.ConnectionEnvFactory.createResource(ConnectionEnvFactory.java:217)
     at weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1109)
     at weblogic.common.resourcepool.ResourcePoolImpl$ResourcePoolMaintanenceTask.timerExpired(ResourcePoolImpl.java:2282)
     at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
     at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
And many more entries like the above...
I even tried startup & Deployment option as "Start weblogic server in Expressmode" and still same error I am getting and this time instead of in eclipse console, I can see command prompt and here also showing "Server state changed to STARTING"
FYI, I created domain with runtime JRocket 1.6.0_05.
I even tried to clean build the portal project and publish using clean option. Still same problem coming :(
FYI, my system is having 1 GB RAM only and bit slow. Could this be a problem or something else? Please suggest.
Thanks in advance.
Edited by: gopikrish on Sep 8, 2011 6:20 AM

Hi Gopikrish
The root cause for your error is, it is not able to start the Pointbase database. Looks like you configured a domain with default pointbase database. In the domain\bin\ one of the starup scripts like startWeblogic.cmd, you should see some lines that start the pointbase database.
java.sql.SQLException: SQL-server rejected establishment of SQL-connection. Pointbase Server may not be running on localhost at port 9093
Instead of starting from Workshop, go to the domain root folder and start the weblogic using the command like startWeblogic.cmd (or .sh on unix). This should start the pointbase and then start the portal domain. Portal domain does need this backend pointbase database to store all the portal meta data and has datasources configured for this.
Do you have a Clustered Portal domain, with one of the managed servers located in the remote machine. If yes, and if you use default Pointbase database, you need to change something like pointbase db should not be localhost but the name of the machine where you have the admin server running.
Either way, the issue is not able to stat the pointbase db and thus serve not starting.
Thanks
Ravi Jegga

Exception when using TIBCO EMS for a WebLogic MDB - intermittent issue

We have a weblogic app that uses an MDB to retreive messages from TIB EMS.
There are no exceptions at first - the messages are retreived and everything works well.
But after a few days and then we see the following exception:
####<Apr 13, 2009 2:11:43 PM EDT> <Error> <Kernel> <dhbpmapp2.is.bear.com> <mngENS_dhbpmapp2> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1239646303673> <BEA-000802> <ExecuteRequest failed
java.lang.ClassCastException: com.tibco.tibjms.naming.TibjmsFederatedQueue.
java.lang.ClassCastException: com.tibco.tibjms.naming.TibjmsFederatedQueue
at weblogic.jms.common.CDS.ddLookup(CDS.java:759)
at weblogic.jms.common.CDS.access$400(CDS.java:37)
at weblogic.jms.common.CDS$DDLookupTimerListener.timerExpired(CDS.java:612)
at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManag erImpl.java:464)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
We do not know why this comes up after a few days.
Any help in tracking this down will be greatly appreciated.
We are using Weblogic Server 10.0

Hi,
This might be happening when the MDB tries to reconnect to the foreign destination.
Have you configured the TIB EMS as Foreign JMS provider in WLS ?
Do you know whether this issue happens only when
1) the MDB gets redeployed ?
2) the server instance that hosts the foreign dest gets bounced?
3) the JMS module that defines the foreign JMS server gets redeployed ?
Anyway, based on a quick search in support cases, looks like this issue has been already fixed.
Please contact the customer support to get the appropriate patch.
Thanks
Kats

Authentication for user weblogic denied seen in Weblogic 8.1 bea logs

I am observing the below error in bea logs of one of my managed servers. The managed server is in running state but the most of the Bridges are inactive with description "WARN: failed to connect to the source". Below is the error seen.
####<Mar 29, 2013 2:17:47 PM GMT> <Notice> <Security> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <ExecuteThread: '36' for queu
e: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-090078> <User weblogic in security realm myrealm has had 5 invalid login
attempts, locking account for 30 minutes.>
####<Mar 29, 2013 2:18:46 PM GMT> <Critical> <Security> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <ExecuteThread: '36' for qu
eue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-090403> <Authentication for user weblogic denied>
####<Mar 29, 2013 2:19:46 PM GMT> <Critical> <Security> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <ExecuteThread: '36' for qu
eue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-090403> <Authentication for user weblogic denied>
####<Mar 29, 2013 2:20:46 PM GMT> <Critical> <Security> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <ExecuteThread: '35' for qu
eue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-090403> <Authentication for user weblogic denied>
####<Mar 29, 2013 2:21:46 PM GMT> <Critical> <Security> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <ExecuteThread: '36' for qu
eue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-090403> <Authentication for user weblogic denied>
####<Mar 29, 2013 2:22:46 PM GMT> <Critical> <Security> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <ExecuteThread: '37' for qu
eue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-090403> <Authentication for user weblogic denied>
####<Mar 29, 2013 2:23:46 PM GMT> <Critical> <Security> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <ExecuteThread: '35' for qu
eue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-090403> <Authentication for user weblogic denied>
####<Mar 29, 2013 2:24:46 PM GMT> <Critical> <Security> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <ExecuteThread: '35' for qu
eue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-090403> <Authentication for user weblogic denied>
####<Mar 29, 2013 2:25:46 PM GMT> <Critical> <Security> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <ExecuteThread: '37' for qu
eue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-090403> <Authentication for user weblogic denied>
####<Mar 29, 2013 2:26:46 PM GMT> <Critical> <Security> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <ExecuteThread: '37' for qu
eue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-090403> <Authentication for user weblogic denied>
####<Mar 29, 2013 2:27:18 PM GMT> <Error> <WebLogicServer> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <weblogic.health.CoreHea
lthMonitor> <<WLS Kernel>> <> <BEA-000337> <ExecuteThread: '32' for queue: 'MessagingBridge' has been busy for "1,614" second
s working on the request "weblogic.jms.bridge.internal.MessagingBridge: gsb2biA:Location=managed1_gsb2biA,Name=managed1_gsb2b
iA.bridge.MB.BPS_TO_SH_4_CBGW_ADAPTOR,ServerRuntime=managed1_gsb2biA,Type=MessagingBridgeRuntime
Set fields: [Name]
Name -> <null>
Parent -> gsb2biA:Location=managed1_gsb2biA,Name=managed1_gsb2biA,Type=ServerRuntime
", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>
####<Mar 29, 2013 2:27:18 PM GMT> <Error> <WebLogicServer> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <weblogic.health.CoreHea
lthMonitor> <<WLS Kernel>> <> <BEA-000337> <ExecuteThread: '33' for queue: 'MessagingBridge' has been busy for "1,614" second
s working on the request "weblogic.jms.bridge.internal.MessagingBridge: gsb2biA:Location=managed1_gsb2biA,Name=managed1_gsb2b
iA.bridge.com.bt.jms.bridge.GSB2B.GSB2B_To_RoBTESB.MDO.FTP.response,ServerRuntime=managed1_gsb2biA,Type=MessagingBridgeRuntim
e
Set fields: [Name]
Name -> <null>
Parent -> gsb2biA:Location=managed1_gsb2biA,Name=managed1_gsb2biA,Type=ServerRuntime
", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>
####<Mar 29, 2013 2:27:18 PM GMT> <Error> <WebLogicServer> <hwspx007.vipx.bt.com> <managed1_gsb2biA> <weblogic.health.CoreHea
lthMonitor> <<WLS Kernel>> <> <BEA-000337> <ExecuteThread: '34' for queue: 'MessagingBridge' has been busy for "1,618" second
s working on the request "weblogic.jms.bridge.internal.MessagingBridge: gsb2biA:Location=managed1_gsb2biA,Name=managed1_gsb2b
iA.bridge.MB_BTGS_B2B_TO_RoBTESB_MPF_PI,ServerRuntime=managed1_gsb2biA,Type=MessagingBridgeRuntime
Set fields: [Name]
Name -> <null>
Parent -> gsb2biA:Location=managed1_gsb2biA,Name=managed1_gsb2biA,Type=ServerRuntime
", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>

Have a look at this... Look for "credential" to see how to fix the username/password of your message bridge...
http://docs.oracle.com/cd/E13222_01/wls/docs81/ConsoleHelp/messaging_bridge.html#1122172
Cheers,
Vlad

No CREATE permission for key: "weblogic.app.internal.AdminMode"

Hi all,
after installing the wls9.2 on a fresh windows xp, trying to open the admin console, I receive the following error:
####<08.05.2008 13.49 Uhr CEST> <Error> <Kernel> <s0043372> <b2bsys1> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.ke
rnel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1210247370797> <BEA-000802> <ExecuteRequest failed
java.security.AccessControlException: No CREATE permission for key: "weblogic.app.internal.AdminMode".
java.security.AccessControlException: No CREATE permission for key: "weblogic.app.internal.AdminMode"
at weblogic.workarea.WorkContextLocalMap.put(WorkContextLocalMap.java:45)
at weblogic.workarea.WorkContextMapImpl.put(WorkContextMapImpl.java:40)
at weblogic.application.utils.ApplicationVersionUtils.setCurrentAdminMode(ApplicationVersionUtils.java:355)
at weblogic.servlet.internal.HttpServer$WorkContextManager.copyThreadContexts(HttpServer.java:816)
at weblogic.servlet.internal.ServletRequestImpl$SessionHelper.syncSession(ServletRequestImpl.java:2479)
at weblogic.servlet.internal.ServletResponseImpl$1.run(ServletResponseImpl.java:1314)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1308)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1371)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
Does anybody has an idea?
Thanks a lot
Dirk

Hi,
I had the same issue regarding WLS8.1 to WLS10 migration with MDBs.
Contacted BEA support. The solution for me was to add a WorkContext
and assign the weblogic.app.internal.AdminMode.
From the Admin console:
1) Create a workcontext
click workcontext -> Work Context Resources -select new-> path: add weblogic.app.internal.AdminMode then "all actions"
Make sure you save them and released the configuration
2) Add the policy to the existing weblogic.app.internal.AdminMode workcontext,
select the work context resource-> weblogic.app.internal.AdminMode -> select Policy tab-> Select
"DefaultAuthorizer" Select "Add Condition"-> Select "Group" Select "Next" -> Add "everyone" into "Group Argument Name" Then save.
That did the trick for me. In cluster and standalone.

ExecuteThread for queue: 'weblogic.kernel.Default' stuck

Similar Messages

Maybe you are looking for