You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Siqi Du <si...@gmail.com> on 2009/09/07 06:28:35 UTC
A bug in monitoring: a non-existent EJB node also can run
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
Re: A bug in monitoring: a non-existent EJB node also can run
Posted by Siqi Du <si...@gmail.com>.
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 <da...@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
>>
>
>
Re: A bug in monitoring: a non-existent EJB node also can run
Posted by David Blevins <da...@visi.com>.
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