geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siqi Du <siqi...@gmail.com>
Subject A bug in monitoring: a non-existent EJB node also can run
Date Mon, 07 Sep 2009 04:28:35 GMT
Hi,

There is a bug in Monitoring portlet of Geronimo 2.2 web console (
GERONIMO-4839 <https://issues.apache.org/jira/browse/GERONIMO-4839>) and I
find it an issue of OpenEJB that the ejb-client treat all connecting tries
in a clustering environment by default. My question is how to let ejb-client
know that I do not want to connect to a ejb cluster.

Thank you.

Here is the detail.

In Monitoring portlet we need to monitor a few ejb nodes, so I use this code
to get the context:

Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY,
    "org.apache.openejb.client.RemoteInitialContextFactory");
props.setProperty(Context.PROVIDER_URL, "ejbd://" + ip + ":" +port);
props.setProperty(Context.SECURITY_PRINCIPAL, userName);
props.setProperty(Context.SECURITY_CREDENTIALS, password);
...
Context ctx = new InitialContext(props);

But all the connecting tries will connect to the target ejb server of first
succeeded connection, even the one with a wrong address. I looked into the
code of  openejb and found something in package org.apache.openejb.client.

In method Client.processRequest() the code always consider we are in a
clustering environment and put the only server in a ClusterMetaData.

In the default connection strategy class StickyConnectionStrategy, they
always try the last lastLocation first, and then the remaining ones. I think
it is the cause of the bug.

BTW, in StickyConnectionStrategy, this part of code:

if (locations.length == 0){
return connect(server.getLocation());
}

I guess it wants to deal with the non-clustering environment, but it will
never run.

-Siqi

Mime
View raw message