Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Exceptions being raised by partitions

3 views
Skip to first unread message

Stuart Malcolm

unread,
Jun 11, 2003, 1:15:02 PM6/11/03
to
All,

When running BES 5.2.1 on Windows 2000, the following exception occurs a lot
on our customer's production system, and it does not happen on their
training or development environments.

I am suspecting that this is occurring because they have 'hardened' their
application servers - any ideas as to what would cause this error? From
looking at the console, all beans are deployed correctly, and the users can
use the application but they experience intermittant 'loss of connection' to
the EDMS (Oracle iFS). The partitions also use a large amount of CPU
continuously even when there is no user activity.

Are there any guidelines as to what can or cannot be 'hardened' on a W2K
server running BES 5.2.1.

Regards,
Stuart

[Wed Jun 11 10:21:26 BST 2003] stderr: java.lang.ClassNotFoundException:
com.kainos.core.CUserStruct
[Wed Jun 11 10:21:26 BST 2003] stderr: at
java.net.URLClassLoader$1.run(URLClassLoader.java:198)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
java.security.AccessController.doPrivileged(Native Method)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
java.net.URLClassLoader.findClass(URLClassLoader.java:186)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
java.lang.ClassLoader.loadClass(ClassLoader.java:299)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
java.lang.ClassLoader.loadClass(ClassLoader.java:255)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.util.RepIdFunctions.loadClass(RepIdFunctions.java:90)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.util.RepIdFunctions.loadClass(RepIdFunctions.java:80)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.util.RepIdFunctions.classFromRepId(RepIdFunctions.java:2
69)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.rmi.CORBA.CodeBaseImpl.implementation(CodeBaseImpl.java:
55)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
org.omg.SendingContext.CodeBasePOA._invoke(CodeBasePOA.java:81)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
org.omg.SendingContext.CodeBasePOA._invoke(CodeBasePOA.java:56)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.poa.POAImpl.invoke(POAImpl.java:2693)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.poa.ActivationRecord.invoke(ActivationRecord.java:109)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.poa.ServerInterceptorManager$ARWrapper.invoke(ServerInte
rceptorManager.java:110)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.GIOP.GiopProtocolAdapter.doRequest(GiopProtocolAdapter.j
ava:824)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.IIOP.ServerProtocolAdapter.doRequest(ServerProtocolAdapt
er.java:68)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.GIOP.GiopProtocolAdapter.dispatchMessage(GiopProtocolAda
pter.java:1106)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.orb.TPDispatcherImpl$TPDispatcher.run(TPDispatcherImpl.j
ava:106)
[Wed Jun 11 10:21:26 BST 2003] stderr: at
com.inprise.vbroker.orb.ThreadPool$PoolWorker.run(ThreadPool.java:76)

Stuart Malcolm

unread,
Jun 12, 2003, 5:07:31 AM6/12/03
to
Further to my previous post, I have upgraded our development environment
from BES 5.2 -> BES 5.2.1, and have deployed the exact same JAR files. This
error is now occurring on the development environment.

Am I missing a new setting?

Regards,
Stuart


Stuart Malcolm

unread,
Jun 12, 2003, 9:14:02 AM6/12/03
to
Another further development and observations:

The partition causing the errors has a class loading policy of 'container'.
The errors identified in my previous post do not occur for a 'per_module'
partition.

1 - JAR's deployed to lib\system, lib\shared or lib\app do not appear in the
console as deployed modules. They do appear in the console when they are
deployed to the lib directory. Is this a bug in the console, or expected
behaviour? The location of where the JAR's are deployed to under the lib
hierarchy does not appear to make a difference, regardless of them being
displayed in the console or not.

2 - If I copy my JARS deployed to the partition's ejb_jars directory to the
lib\system directory, the exception is no longer raised.

It seems that the partition cannot locate class files within the ejb_jars
directory; I thought that when the classloading policy was set to
'container' that all the JARS deployed within ejb_jars would be able to
'see' all the classes within the other JARS also deployed to ejb_jars?

Regards,
Stuart

brawnski

unread,
Jun 16, 2003, 6:21:57 PM6/16/03
to
Experiencing the same errors.
however, my class loading policy *is* set to per_module

the VBJ Worker Thread is trying to load my return object.
those classes are in the partitions shared class loader.
the vbj thread pool is in the partitions system class loader.

i would just move the jars to the partitions system loader,
but the corba call always succeeds and the class not found exceptions
are thrown afterward. makes me think its a bes/vbroker bug and i
shouldnt change my code.

0 new messages