Skip to main content

This error was found in my ManagedServer1.out#####. 

After many occurrences of this error, I began to see many STUCK threads with more BEA-050007 errors interspersed.

 

<Sep 27, 2022 7:53:02 AM MST> <Warning> <JNDI> <BEA-050007> <An attempt was made to look up the non-versioned global resource "" from an application version "ifsapp pVersion=2018-12-16_07.56.19]". This can potentially cause conflict of the global resource usages among multiple application versions.>


<Sep 27, 2022 7:53:06 AM MST> <Error> <WebLogicServer> <BEA-000337> <tSTUCK] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "604" seconds working on the request "Workmanager: default, Version: 0, Scheduled=true, Started=true, Started time: 604118 ms
", which is more than the configured time (StuckThreadMaxTime) of "600" seconds in "server-failure-trigger". 

 

When this happens the application is no longer accessible and the only recourse I have is to stop and start it.

 

Any suggestions are welcome.
 

 

The stuck messages were caused by a problem with an NFS mount where we store our IFS-Docs. It repeatedly dropped and the java processes that were trying to access it became stuck. Unfortunately the stuck threads had not reported why they were stuck so it took a while to identify the root cause.

The stuck messages were caused by a problem with an NFS mount where we store our IFS-Docs. It repeatedly dropped and the java processes that were trying to access it became stuck. Unfortunately the stuck threads had not reported why they were stuck so it took a while to identify the root cause.

Hello @dmanuele,

There is a similar warning in the our logs. Can you share details about the solution?

Baris,

Our Oracle database is running on a Linux server. For document storage we have created an NFS mount point to a network file share server.  We have defined a directory object in the database that uses a path on the NFS mount point.

We had a problem where we lost access to the NFS mount point. When this happened, IFS continued to try to access it and did not time out. The JAVA process (thread) that initiated it became STUCK. As more and more threads became stuck, fewer were available to do work. Users began competing for the limited resources until things ground to a halt.

 

We did not have a monitor that warned us of the dropped NFS mount. It was only after engaging our IT Operations group that they discovered the problem with the NFS mount. Once they restored the mount point the issue went away.

 

I hope this helps.

Reply


Terms & ConditionsCookie settings