geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siqi Du <siqi...@gmail.com>
Subject Re: A bug in monitoring: a non-existent EJB node also can run
Date Fri, 11 Sep 2009 04:16:28 GMT
I use a private build of openejb-client in Geronimo, and it works
well. Thank you, David.
BTW, it seems that the latest openejb official build hasn't been uploaded to
the maven repo, so we need to wait.

-Siqi

On Thu, Sep 10, 2009 at 4:14 PM, David Blevins <david.blevins@visi.com>wrote:

> Ok, this should be fixed as of revision 813292.  Give it a try and let me
> know how it goes.
>
> -David
>
>
> On Sep 6, 2009, at 9:28 PM, Siqi Du wrote:
>
>  Hi,
>>
>> There is a bug in Monitoring portlet of Geronimo 2.2 web console
>> (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