[
http://jira.jboss.com/jira/browse/JBCLUSTER-187?page=all ]
Vijesh updated JBCLUSTER-187:
-----------------------------
Summary: Local instead of remote lookup happens when bean is clustered (in server
to server calls) (was: Local instead of remote lookup happens when bean is clustered)
Description:
1) Two different ejb 2.1 applications. Let's call them A1 and A2
2) Both has some common beans deployed in them (same jar). Lets call them C1, C2 etc. Each
application also has their own bean: let's call them A1-a, A-b etc and A2-x, A2-y etc
3) A1 to A2 communication via remote call is there. And clients can call any beans
(common/specific) A1 and A2 also.
4) Let's say a client calls the bean A1-a deployed in A1. A1-a in turn calls the bean
C1 in application A2. Though C1 deployed in both servers are same, the data supplied them
are different, so the call has to reach A2.
The issue.
When the beans are not clustered, call from A1-a to C1 in A2 went through as expected (in
both all/default configurations).
But when the beans are clustered, instead of calling C1 in A2, local lookup is done and
invoked C1 in application A1.
Expected behaviour:
In both clustered and non-clustered configuration, when a remote bean look up is done from
application-1 to another bean in application-2, which is also present in application-1,
the call should go to application-2
Jboss; 4.0.5
jdk: 1.5_05
ejb; 2.1
stateless beans
was:
1) Two different ejb 2.1 applications. Let's call them A1 and A2
2) Both has some common beans deployed in them (same jar). Lets call them C1, C2 etc. Each
application also has their own bean: let's call them A1-a, A-b etc and A2-x, A2-y etc
3) A1 to A2 communication via remote call is there. And clients can call any beans
(common/specific) A1 and A2 also.
4) Let's say a client calls the bean A1-a deployed in A1. A1-a in turn calls the bean
C1 in application A2. Though C1 deployed in both servers are same, the data supplied them
are different, so the call has to reach A2.
The issue.
When the beans are not clustered, call from A1-a to C1 in A2 went through as expected (in
both all/default configurations).
But when the beans are clustered, instead of calling C1 in A2, local lookup is done and
invoked C1 in application A1.
Expected behaviour:
In both clustered and non-clustered configuration, when a remote bean look up is done from
application-1 to another bean in application-2, which is also present in application-1,
the call should go to application-2
Jboss; 4.0.5
jdk: 1.5_05
ejb; 2.1
stateless beans
Local instead of remote lookup happens when bean is clustered (in
server to server calls)
-----------------------------------------------------------------------------------------
Key: JBCLUSTER-187
URL:
http://jira.jboss.com/jira/browse/JBCLUSTER-187
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public(Everyone can see)
Environment: Linux/Widows
Reporter: Vijesh
Assigned To: Brian Stansberry
1) Two different ejb 2.1 applications. Let's call them A1 and A2
2) Both has some common beans deployed in them (same jar). Lets call them C1, C2 etc.
Each application also has their own bean: let's call them A1-a, A-b etc and A2-x, A2-y
etc
3) A1 to A2 communication via remote call is there. And clients can call any beans
(common/specific) A1 and A2 also.
4) Let's say a client calls the bean A1-a deployed in A1. A1-a in turn calls the
bean C1 in application A2. Though C1 deployed in both servers are same, the data supplied
them are different, so the call has to reach A2.
The issue.
When the beans are not clustered, call from A1-a to C1 in A2 went through as expected (in
both all/default configurations).
But when the beans are clustered, instead of calling C1 in A2, local lookup is done and
invoked C1 in application A1.
Expected behaviour:
In both clustered and non-clustered configuration, when a remote bean look up is done
from application-1 to another bean in application-2, which is also present in
application-1, the call should go to application-2
Jboss; 4.0.5
jdk: 1.5_05
ejb; 2.1
stateless beans
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira