Win a copy of Head First Android this week in the Android forum!

Eddi Alfare

+ Follow
since Jan 10, 2010
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Eddi Alfare

Thanks for the reply,

I was looking for a way to dynamically prevent OOME.
I wanted to implement an 'OutofMemoryERROR Warning System' as described in OOME Warning System,
but in stead of reacting to a pending OOME by increasing the PercentageUsageThreshold (at runtime), I wanted this system to find the culprit thread (which was allocating all these objects) and 'kill it'.
Is this feasible ?

11 years ago

can anyone explain to me why an OutOfMemoryException caused by a specific application, doesn't only cause that
application to crash, but also the entire appserver ?

this is the situation:

Appserver_0 and Appserver_1
both running EAR_0 (and other EARS as well)

Now because a user requests a particularly large dataset, the EAR_0 application runs out of memory.
Result : ClusterGroup_0 crashes.

What I want is for only EAR_0 (the application) to crash, or - even better - only that particular user session.

Is this possible ?
11 years ago

I am using Websphere 6.0 and ejb 2.0 and a WebStart client.
I have 2 appservers running in one cluster on different nodes.
What I want to achieve, is to have a particular ejb method to be invoked on both appservers.
(Normally, because of the WorkLoad Management facility in Websphere, any remote ejb-call will result into only one of the appservers executing this method.)

This is what I tried to 'bypass' this WLM for this particular ejb-method call :

On the client I perform two lookups of the ejb, each time with a different InitialContext to connect to each specific appserver.
My code to create the InitialContext is as follows:

The values for providerUrl are
  • corbaloc::hostNameAppServer1:nodeAgent1Port
  • corbaloc::hostNameAppServer2:nodeAgent2Port

  • (nodeAgentXPort is the bootstrap port of the nodeagent on which appServerX is running.)

    I then look up the ejb ref on each InitialContext and invoke the ejb method on each ejb ref.

    When I run this code, most of the times both method calls are directed to the same appserver.

    It seems like Websphere's "smart client stubs" cannot be fooled and still load balance whether I like it or not.

    Any ideas on how I could bypass the workload manager for this particular ejb ?


    If you get a ClassNotFoundException, this means the jar containing the org.jboss.iiop.naming.ORBInitialContextFactory class is not in your client's classpath.