Replica-aware stub.

Hi,
Can anyone explain about replica aware stub.
Thanks in advance.
Regards,
Vardhan.

Hi Vardhan,
Please refer to : http://download.oracle.com/docs/cd/E11035_01/wls100/cluster/overview.html
Load balancing and failover for EJBs and RMI objects is handled using replica-aware stubs, which can locate instances of the object throughout the cluster. Replica-aware stubs are created for EJBs and RMI objects as a result of the object compilation process. EJBs and RMI objects are deployed homogeneously—to all the server instances in the cluster.
Failover for EJBs and RMI objects is accomplished using the object’s replica-aware stub. When a client makes a call through a replica-aware stub to a service that fails, the stub detects the failure and retries the call on another replica. To understand failover support for different types of objects, see Replication and Failover for EJBs and RMIs.
WebLogic Server clusters support multiple algorithms for load balancing clustered EJBs and RMI objects: round-robin, weight-based, random, round-robin-affinity, weight-based-affinity, and random-affinity. By default, a WebLogic Server cluster will use the round-robin method. You can configure a cluster to use one of the other methods using the Administration Console. The method you select is maintained within the replica-aware stub obtained for clustered objects. For details, see Load Balancing for EJBs and RMI Objects.
Above kind of Stubs are available only for *"EJBs and RMI Objects"* when we deploy an EJB/RMI based application on Cluster.

Similar Messages

Questions on InitialContext and replica-aware stub caching

Hi All,
We have a cluster and deployed with some stateless ejb session beans. Currently we only cached the InitialContext object in the client code, and I have several questions:
1. in the current case, if we call lookup() to get a replica-aware stub, which server will return the stub object, the same server we get the InitialContext, or it will load balanced to other servers every time we call the lookup method?
2. should we just cache the stub? is it thread safe? if it is, how does the stub handle concurrent requests from the client threads? in parallels or in sequence?
One more question, when we call new InitialContext(), it will take a long time before it can return a timeout exception if the servers are not reachable, how can we set a timeout for this case?

809364 wrote:
You can set the timeout value programatically by using the
weblogic.jndi.Environment.setRequestTimeout()
Refer: http://docs.oracle.com/cd/E12839_01/apirefs.1111/e13941/weblogic/jndi/Environment.html
or
set the REQUEST_TIMEOUT in the weblogic.jndi.WLContext
Refer: http://docs.oracle.com/cd/E11035_01/wls100/javadocs/weblogic/jndi/WLContext.html
Hi, I tried setting the parameters before, but it only works for stub lookup and ejb call timeout, not for the creation of InitialContext. And any idea for my 2nd question?

Is Replica aware stubs are in infinite loop when fail over????

          Hi
          Any help on this Appreciated
          See in this senario, where there is four weblogic instance runs in the cluster
          and a replica aware stub(stateless bean with idempodent methods) finds a particular
          method fails on a server and it redircets the request to another one server but the
          same method fails on all the server, then what is goin to happen?? is it going to
          throw some exception or gonna be in a loop to keep on redirecting the method request
          to all servers in Round???
          Regards
          Aruna


          Aruna,
          A stateless session bean whose methods have been declared idempotent will automatically
          retry on another service provider in a fail-over situation. When a fail-over situation
          occurs, the stub refreshes its list of service providers. Note: Just because your
          method call fails, doesn't mean it's a fail-over situation.
          Jane
          "Aruna" <[email protected]> wrote:
          >
          >Hi
          >
          > Any help on this Appreciated
          >
          > See in this senario, where there is four weblogic instance runs in
          >the cluster
          >and a replica aware stub(stateless bean with idempodent methods) finds a
          >particular
          >method fails on a server and it redircets the request to another one server
          >but the
          >same method fails on all the server, then what is goin to happen?? is it
          >going to
          >throw some exception or gonna be in a loop to keep on redirecting the method
          >request
          >to all servers in Round???
          >
          >
          >Regards
          >Aruna

RMI callbacks with no replica aware stubs in a cluster?

We would like to use either an RMI ping mechanism or an RMI callback in an upcoming project but are limited to 1.1 and 1.2 JRE's. I don't believe generating a replica aware proxy is an option for us given those constraints, no support for dynamic proxies. So we have a remote server object that we would ideally like to be clusterable that we can register a callback interface with. How can we accomplish this given our client limitations with weblogic 8.1 RMI? Any options?

Yep you speak no lies. Of course once I thought about it some more I realized the error of assuming one could register a jdk rmi object with a weblogic rmi object. JRMP vs T3?. Not good.
We still like using plain jane RMI w/in weblogic. I can register my UnicastRemoteObject stub with a normal RMI object on the server and it can callback and deliver messages. It will also send heartbeats periodically. If the heartbeat isn't heard from in awhile we re-register through http. The advantage of this is that the http session has failed over to another box and the web tier manages the rmi registration for me. The client can remain ignorant of any RMI lookups, which are tedious when not using JNDI or the cluster aware proxy.
All of this to get back a few seconds and keep a few thousand clients from polling through a servlet every second. Argh JDK 1.1.
Thanks for hammering that final point in.

Re-deploying replica aware EJBs

          How does one update an app server with a new EJB when the app server
          is running in a cluster? Doing a re-deploy on the EJB in a single instance
          can even be a problem. First, you can have beans that are cached and
          in use. locking the server and waiting until the last client has completed
          it's operation until you do the redeploy should work. With clustered SLSBs
          the replica aware stubs get distributed by JNDI so until all the servers
          in the cluster have the update the classes are out of sync.
          It seems like you have to bounce all the app servers in the cluster. Not
          a very amicable solution.


In article <[email protected]>, [email protected] says...
          >
          > How does one update an app server with a new EJB when the app server
          > is running in a cluster? Doing a re-deploy on the EJB in a single instance
          > can even be a problem. First, you can have beans that are cached and
          > in use. locking the server and waiting until the last client has completed
          > it's operation until you do the redeploy should work. With clustered SLSBs
          > the replica aware stubs get distributed by JNDI so until all the servers
          > in the cluster have the update the classes are out of sync.
          >
          > It seems like you have to bounce all the app servers in the cluster. Not
          > a very amicable solution.
          >
          >
          >
          Mike,
          This is a toughy and something I've been trying to figure out for a
          while. Maybe together we'll devise a strategy so here's what I've come
          up with so far:
          Maintain a set of "upgrade servers" on another network line (using a
          switch). When upgrading, bring them online into the main cluster and
          then start kiling the main machines. When they're all dead, unplug them
          from the network and begin the upgrade. Test the upgrade after bringing
          the new main cluster back up. Once confirmed, start locking out
          transactions, etc from the backup cluster and have the web front end
          give a "down for X minutes message to all new requests". Once the
          backup app servers have no more requests, unplug them from the network
          and plug the new app servers in. Reopen the flood gates at the front
          end. You'll still lose some sessions, but this should be in a service
          level agreement and be understood by customers.
          Some variations, in case the switch isn't manageable and being
          physically there is not on option would be to bring various interfaces
          up and down to meet the needs described above.
          It's not perfect; uptime is still purposely limited, but these are thing
          that should be defined in any agreement you make with customers. Even
          NASDAQ goes down. I'm currently working on a strategy for WebLogic 6.0
          JT

Replica aware

Hi,
          I am an absolute newbie in the world of web logic clustering. I am reading
          the article "How Clusters work" in WLS 5.1 documentation.
          I am not quite sure as to what do the term 'Replic aware'.
          It will be great if some one could explain that
          regards,
          Abhishek.


          Replica aware means this stub can be smart enough to know how many replicas(each replica means a deployed service on one server in the cluster) it represents and the detail information about these replicas(ie. it's ip address.)
          The replica-aware stub can support load-balance and fail over accroding to these information. suppose if one replica fails, the stub can remove this replica from this stub and fail over to other.
          Hope this can help you.
          Abhishek <abisheks@no_spam.india.hp.com> wrote:
          >Hi,
          >
          >I am an absolute newbie in the world of web logic clustering. I am reading
          >the article "How Clusters work" in WLS 5.1 documentation.
          >
          >I am not quite sure as to what do the term 'Replic aware'.
          >
          >It will be great if some one could explain that
          >
          >regards,
          >Abhishek.
          >

ASSERTION FAILED of replica-related stub in a non-clustered SLSB

Wl 6.1 sp2
Solaris 2.8
We have 50 SLSBs running on non-clustered WL servers. Yet we are seeing
the following ASSERTION FAILED error, which from the stacktrace seems to
hint the ejb stub is doing something cluster-related... I have attached
ejb-jar.xml of the offending bean; someone please verify we are not
building cluster-capable stubs, and if we are building the right stub,
please explain why the exception is happening. Thanks!
******** STACKTRACE
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Assertion
violated ]
at weblogic.utils.Debug.assert(Debug.java:74)
at weblogic.rmi.cluster.BasicReplicaList.reset(BasicReplicaList.java:175)
at
weblogic.rmi.cluster.PrimarySecondaryReplicaHandler.setPiggybackResponse(Pri
marySecondaryReplicaHandler.java:94)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.setPiggybackResponse(ReplicaAware
RemoteRef.java:294)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
:265)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
:229)
at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
at $Proxy14.getStatus(Unknown Source)
at
com.go2.dtc.service.AccountStatus.accountIsOnline(AccountStatus.java:57)
******* EJB-JAR.XML
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<home>com.go2.ejb.services.accountservice.AccountServiceHome</home>
<remote>com.go2.ejb.services.accountservice.AccountService</remote>
<ejb-class>com.go2.ejb.services.accountservice.AccountServiceBean</ejb-class
>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getStatus</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>changeSearchListingStatus</method-name>
<method-params>
<method-param>int</method-param>
<method-param>java.lang.String</method-param>
</method-params>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
</assembly-descriptor>
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<home>com.go2.ejb.services.accountservice.AccountServiceHome</home>
<remote>com.go2.ejb.services.accountservice.AccountService</remote>
<ejb-class>com.go2.ejb.services.accountservice.AccountServiceBean</ejb-class
>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getStatus</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>changeSearchListingStatus</method-name>
<method-params>
<method-param>int</method-param>
<method-param>java.lang.String</method-param>
</method-params>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>

Hi Rajesh,
This error was reported on our QA system error log, and only occurred a
couple of times in a very specific time frame. I will ask QA again if it
has happened since the first report.
However, even if this bug is minor and not production-worthy, what I am more
concerned about is the fact that the stacktrace seem to indicate the bug is
cluster-related, when we set our SLSBs to be non-clustered. Can someone
please confirm, given the ejb-jar.xml and weblogic-ejb-jar.xml I've posted
below, that I have properly configured and deployed our beans to be
non-clustered? I don't want to introduce cluster overhead (and cluster
bugs) when we don't need to!
Gene
"Rajesh Mirchandani" <[email protected]> wrote in message
news:[email protected]...
The reason I asked you if it is readily reproducable is because I had seenthis
issue (support case) in WLS 6.1(no sp). The problem there was that itcould not
be reproduced again and so I did not analyze it further.
Is this happening under load ?
Gene Chuang wrote:
Hi Rob,
AccountStatus is calling AccountService, which is a SLSB. I have
attached
its ejb-jar.xml in my original post, and here's the corresponding
weblogic-ejb-jar.xml:
!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic6.0.0
EJB//EN' 'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>

<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<stateless-session-descriptor>
<pool>
<max-beans-in-free-pool>100</max-beans-in-free-pool>
</pool>
<stateless-clustering>
<stateless-bean-is-clusterable>False</stateless-bean-is-clusterable>
>>
>>
<stateless-bean-methods-are-idempotent>False</stateless-bean-methods-are-ide
mpotent>
</stateless-clustering>
</stateless-session-descriptor>
<transaction-descriptor>
<trans-timeout-seconds>300</trans-timeout-seconds>
</transaction-descriptor>
<jndi-name>accountservice.AccountServiceHome</jndi-name>
</weblogic-enterprise-bean>
<transaction-isolation>
<isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>*</method-name>
</method>
</transaction-isolation>
</weblogic-ejb-jar>
"Rob Woollen" <[email protected]> wrote in message
news:[email protected]...
It looks like AccountStatus is calling a stateful session bean that
uses
in-memory replication. (The PrimarySecondary stub is only used forin-memory
replicated sfsb.)
Do you have any sfsb?
-- Rob
Gene Chuang wrote:
Wl 6.1 sp2
Solaris 2.8
We have 50 SLSBs running on non-clustered WL servers. Yet we are
seeing
the following ASSERTION FAILED error, which from the stacktrace
seems to
hint the ejb stub is doing something cluster-related... I haveattached
ejb-jar.xml of the offending bean; someone please verify we are not
building cluster-capable stubs, and if we are building the rightstub,
please explain why the exception is happening. Thanks!
******** STACKTRACE
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[Assertion
violated ]
at weblogic.utils.Debug.assert(Debug.java:74)
atweblogic.rmi.cluster.BasicReplicaList.reset(BasicReplicaList.java:175)
at
weblogic.rmi.cluster.PrimarySecondaryReplicaHandler.setPiggybackResponse(Pri
marySecondaryReplicaHandler.java:94)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.setPiggybackResponse(ReplicaAware
RemoteRef.java:294)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
:265)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
:229)
at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
at $Proxy14.getStatus(Unknown Source)
at
com.go2.dtc.service.AccountStatus.accountIsOnline(AccountStatus.java:57)
>>>>
******* EJB-JAR.XML
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<home>com.go2.ejb.services.accountservice.AccountServiceHome</home>
><remote>com.go2.ejb.services.accountservice.AccountService</remote>
<ejb-class>com.go2.ejb.services.accountservice.AccountServiceBean</ejb-class
>>>>>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getStatus</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>changeSearchListingStatus</method-name>
<method-params>
<method-param>int</method-param>
<method-param>java.lang.String</method-param>
</method-params>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
</assembly-descriptor>
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<home>com.go2.ejb.services.accountservice.AccountServiceHome</home>
><remote>com.go2.ejb.services.accountservice.AccountService</remote>
<ejb-class>com.go2.ejb.services.accountservice.AccountServiceBean</ejb-class
>>>>>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getStatus</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>accountservice.AccountServiceHome</ejb-name>
<method-intf>Remote</method-intf>
<method-name>changeSearchListingStatus</method-name>
<method-params>
<method-param>int</method-param>
<method-param>java.lang.String</method-param>
</method-params>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>--
Rajesh Mirchandani
Developer Relations Engineer
BEA Support

Calling a method on all replicas of a bean in one shot

          Hi,
          Is there any properties by which one can make a replica aware stub direct a method call to all
          instances of the bean in a cluster? The requirement is to update data cached in all instances
          of a bean in the cluster by invoking a method on all instances of the bean.
          Regards,
          Sreeja


          You can try to think about the issue in another way.
          Hope this link can help you.
          http://www.weblogic.com/docs51/classdocs/API_jndi.html#exactlyOnce
          If you do want to do it in your way.
          Try to use JMS Topic. One server can send a topic of updating and all other servers subscribe this topic.
          Good luck.
          Tao Zhang
          "Sreeja" <[email protected]> wrote:
          >
          >Hi,
          >Is there any properties by which one can make a replica aware stub direct a method call to all
          >instances of the bean in a cluster? The requirement is to update data cached in all instances
          >of a bean in the cluster by invoking a method on all instances of the bean.
          >Regards,
          >Sreeja

EJB home stubs in a cluster

The following URL describes how replica-aware EJB home stubs work. Basically,
when you do a lookup for the EJB home in JNDI, you get a home stub on any of the
nodes in the cluster.
However, I want to invoke EJBs on a particular node in the cluster. Can I do
this by simply disabling the replica-aware EJB home in the deployment descriptor
and doing a remote JNDI lookup on the desired node in the cluster? And if so,
would I have to bind each EJB's home to JNDI with a different name?
-reza
http://edocs.bea.com/wls/docs61/cluster/object.html#1006777
All bean homes can be clustered. When a bean is deployed on a server, its home
is bound into the cluster-wide naming service.
Because homes can be clustered, each server can bind an instance of the home under
the same name. When a client looks up this home, it gets a replica-aware stub
that has a reference to the home on each server that deployed the bean. When create()
or find() is called, the replica-aware stub routes the call to one of the replicas.
The home replica receives the find() results or creates an instance of the bean
on this server.

However, I want to invoke EJBs on a particular node in the cluster. Can Ido
this by simply disabling the replica-aware EJB home in the deploymentdescriptor
and doing a remote JNDI lookup on the desired node in the cluster? Andif so,
would I have to bind each EJB's home to JNDI with a different name?Yes. Something like that. We do that with JMS queues sometimes (to send a
message to a particular machine in the cluster).
Peace,
Cameron Purdy
Tangosol, Inc.
Clustering Weblogic? You're either using Coherence, or you should be!
Download a Tangosol Coherence eval today at http://www.tangosol.com/
"Behforooz" <[email protected]> wrote in message
news:3c8fc8bf$[email protected]..
>

Rad-only Entity beans are replicated?

Hi. I have just read the document "Failover and Replication in a cluster": http://edocs.bea.com/wls/docs81/cluster/failover.html#1008850
I have no clear if read-only entity beans are replicated?
I understand that replica-aware stub does not mean that stub objects are replicated in all the servers of the cluster. This seems to be only for statefull session beans.
Thx.

Hi,
we use read only entity beans. It is beneficial if have findByPrimaryKey finders. but we also have finders on non primary key coloumn also. is there a way to cache such local references returned by such non primary key finders also.

Unable to bind a cluster-aware stateless session EJBObject to the name

I have been struggling with "Unable to deploy EJB" because of
"Unable to bind a cluster-aware stateless session EJBObject to the name"
I'm using WL6.1 sp2.
Anyone could give me a hint?
Thanks!

In config.xml remove the <Application></Application> tag for Ejb.
Application Deployed="" Name=""
Path="">
<EJBComponent Name="" Targets="" URI=""/> </Application>
gary <[email protected]> wrote:
Hi guys, hope you can help:
I had to change the packages of some ejbs and now when I try to deploy
the new .jar file I get the error below. I have tried deleting the ejb's
off the server, rebooted the server and nothing seems to work. Any help
would be appreciated. (Weblogic version 6.1)
Thanks in advance,
Gary
Unable to deploy EJB: quizinterface from etvquiz-ejb.jar:
Unable to bind a cluster-aware stateless session EJBObject to the name:
channel4.quizinterface_EO. Please ensure that the jndi-name in the weblogic-ejb-jar.xml
is correct. The error was:
javax.naming.NameAlreadyBoundException: Can't rebind anything but a replica-aware
stub to a name that is currently bound to a replica-aware stub; remaining
name ''
<<no stack trace available>>
>
<Nov 1, 2002 1:57:46 PM GMT> <Error> <Management> <Error deploying application
.\config\mydomain\app
lications\etvquiz: java.lang.reflect.UndeclaredThrowableException>

Client stubs

Hi,
          A question from the "How clusters work" document from the wls 5.1 docs.
          "Clients that connect to a WebLogic Server cluster and look up a
          clustered service obtain a replica-aware stub for the service. This stub
          contains the list of available server instances that host the object. "
          What does 'obtain a replica aware stub' mean ? does it mean that the
          stub is downloaded to the client's machine over the network ? ( like an
          applet ?)
          regards,
          Abhishek.


You don't need to deploy the ejb stubs if you use a standalone client
          talking to a wl 5.1 cluster (I guess the stub is downloaded or created on
          the fly in this case).
          However if you intend to have one wl cluster to talk to another then you
          need to deploy the ejb stubs to the "client cluster" (Don't ask me why?).
          As Cameron mentioned, the "best" way is to create the client jar file by
          extracting the desired classes from the post ejbc jar.
          Cheers
          Bernie
          "Cameron Purdy" <[email protected]> wrote in message
          news:[email protected]...
          > There's no official way that I know of. I just build a client jar by
          hand,
          > extracting the necessary classes out of the post-EJBC jar.
          >
          > Peace,
          >
          > --
          > Cameron Purdy
          > Tangosol, Inc.
          > http://www.tangosol.com
          > +1.617.623.5782
          > WebLogic Consulting Available
          >
          >
          > "Mike Kincer" <[email protected]> wrote in message
          > news:[email protected]...
          > > Question:
          > > The stubs are compiled by ejbc and put in each associated bean .jar
          file.
          > > What is the "official" way to access these stubs from the client side??
          > >
          > > I'm running a 3-tier cluster config presentation (jsp/servlets) on one,
          > EJBs on
          > > another.
          > > I correctly getInitialContext() from t3 services, do the lookup(), but
          > fail to
          > > find the stub class.
          > > I have too many beans to put each bean .jar file in the WL classpath. So
          I
          > have
          > > unpacked
          > > each bean's *Stub.class file and placed them in the WL classpath. So
          far,
          > it
          > > works.
          > >
          > > I'm not clear what you mean when you say stubs are downloaded when you
          do
          > a
          > > lookup.
          > > Downloaded from where?
          > >
          > > Prasad Peddada wrote:
          > >
          > > > Abhishek wrote:
          > > >
          > > > > Hi,
          > > > >
          > > > > A question from the "How clusters work" document from the wls 5.1
          > docs.
          > > > >
          > > > > "Clients that connect to a WebLogic Server cluster and look up a
          > > > > clustered service obtain a replica-aware stub for the service. This
          > stub
          > > > > contains the list of available server instances that host the
          object.
          > "
          > > > >
          > > > > What does 'obtain a replica aware stub' mean ? does it mean that the
          > > > > stub is downloaded to the client's machine over the network ? ( like
          > an
          > > > > applet ?)
          > > >
          > > > Yes, stubs are downloaded when you do a lookup to the client.
          > > > ReplicaAware stubs are capable of doing loadbalancing and failover
          when
          > you
          > > > have more than one server in the cluster.
          > > >
          > > > Typically the stubs is capable of invoking a method on a remote object
          > on
          > > > just one server. Replica Aware stubs are capable for reaching more
          than
          > on
          > > > server.
          > > >
          > > > Hope this helps.
          > > >
          > > > - Prasad
          > > >
          > > > >
          > > > > regards,
          > > > > Abhishek.
          > >
          > > --
          > > /\/\i|<e
          > >
          > > Mike Kincer
          > > Solutions Developer/Engineer
          > > Atlas Commerce "ebusiness evolved"
          > > Office phone: +1-607-741-9988
          > > mailto:[email protected] [http://www.atlascommerce.com]
          > >
          > >
          >
          >

Accessing the same stateful session bean from multiple clients in a clustered environment

I am trying to access the same stateful session bean from multiple
          clients. I also want this bean to have failover support so we want to
          deploy it in a cluster. The following description is how we have tried
          to solve this problem, but it does not seem to be working. Any
          insight would be greatly appreciated!
          I have set up a cluster of three servers. I deployed a stateful
          session bean with in memory replication across the cluster. A client
          obtains a reference to an instance of one of these beans to handle a
          request. Subsequent requests will have to use the same bean and could
          come from various clients. So after using the bean the first client
          stores the handle to the bean (actually the replica aware stub) to be
          used by other clients to be able to obtain the bean. When another
          client retrieves the handle gets the replica aware stub and makes a
          call to the bean the request seems to unpredictably go to any of the
          three servers rather than the primary server hosting that bean. If the
          call goes to the primary server everything seems to work fine the
          session data is available and it gets backed up on the secondary
          server. If it happens to go to the secondary server a bean that has
          the correct session data services the request but gives the error
          <Failed to update the secondary copy of a stateful session bean from
          home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          to the primary server will not reflect changes made on the secondary
          and vice versa. If the request happens to go to the third server that
          is not hosting an instance of that bean then the client receives an
          error that the bean was not available. From my understanding I thought
          the replica aware stub would know which server is the primary host for
          that bean and send the request there.
          Thanks in advance,
          Justin


          If 'allow-concurrent-call' does exactly what you need, then you don't have a problem,
          do you?
          Except of course if you switch ejb containers. Oh well.
          Mike
          "FBenvadi" <[email protected]> wrote:
          >I've got the same problem.
          >I understand from you that concurrent access to a stateful session bean
          >is
          >not allowed but there is a
          >token is weblogic-ejb-jar.xml that is called 'allow-concurrent-call'
          >that
          >does exactly what I need.
          >What you mean 'you'll get a surprise when you go to production' ?
          >I need to understand becouse I can still change the design.
          >Thanks Francesco
          >[email protected]
          >
          >"Mike Reiche" <[email protected]> wrote in message
          >news:[email protected]...
          >>
          >> Get the fix immediately from BEA and test it. It would be a shame to
          >wait
          >until
          >> December only to get a fix - that doesn't work.
          >>
          >> As for stateful session bean use - just remember that concurrent access
          >to
          >a stateful
          >> session bean is not allowed. Things will work fine until you go to
          >production
          >> and encounter some real load - then you will get a surprise.
          >>
          >> Mike
          >>
          >> [email protected] (Justin Meyer) wrote:
          >> >I just heard back from WebLogic Tech Support and they have confirmed
          >> >that this is a bug. Here is their reply:
          >> >
          >> >There is some problem in failover of stateful session beans when its
          >> >run from a java client.However, it is fixed now.
          >> >
          >> >The fix will be in SP2 which will be out by december.
          >> >
          >> >
          >> >Mike,
          >> >Thanks for your reply. I do infact believe we are correctly using
          >a
          >> >stateful session bean however it may have been misleading from my
          >> >description of the problem. We are not accessing the bean
          >> >concurrently from 2 different clients. The second client will only
          >> >come into play if the first client fails. In this case we want to
          >be
          >> >able to reacquire the handle to our stateful session bean and call
          >it
          >> >from the secondary client.
          >> >
          >> >
          >> >Justin
          >> >
          >> >"Mike Reiche" <[email protected]> wrote in message
          >news:<[email protected]>...
          >> >> You should be using an entity bean, not a stateful session bean
          >for
          >> >this application.
          >> >>
          >> >> A stateful session bean is intended to be keep state (stateful)
          >for
          >> >the duration
          >> >> of a client's session (session).
          >> >>
          >> >> It is not meant to be shared by different clients - in fact, if
          >you
          >> >attempt to
          >> >> access the same stateful session bean concurrently - it will throw
          >> >an exception.
          >> >>
          >> >> We did your little trick (storing/retrieving handle) with a stateful
          >> >session bean
          >> >> on WLS 5.1 - and it did work properly - not as you describe. Our
          >sfsb's
          >> >were not
          >> >> replicated as yours are.
          >> >>
          >> >> Mike
          >> >>
          >> >> [email protected] (Justin Meyer) wrote:
          >> >> >I am trying to access the same stateful session bean from multiple
          >> >> >clients. I also want this bean to have failover support so we want
          >> >to
          >> >> >deploy it in a cluster. The following description is how we have
          >tried
          >> >> >to solve this problem, but it does not seem to be working. Any
          >> >> >insight would be greatly appreciated!
          >> >> >
          >> >> >I have set up a cluster of three servers. I deployed a stateful
          >> >> >session bean with in memory replication across the cluster. A client
          >> >> >obtains a reference to an instance of one of these beans to handle
          >> >a
          >> >> >request. Subsequent requests will have to use the same bean and
          >could
          >> >> >come from various clients. So after using the bean the first client
          >> >> >stores the handle to the bean (actually the replica aware stub)
          >to
          >> >be
          >> >> >used by other clients to be able to obtain the bean. When another
          >> >> >client retrieves the handle gets the replica aware stub and makes
          >> >a
          >> >> >call to the bean the request seems to unpredictably go to any of
          >the
          >> >> >three servers rather than the primary server hosting that bean.
          >If
          >> >the
          >> >> >call goes to the primary server everything seems to work fine the
          >> >> >session data is available and it gets backed up on the secondary
          >> >> >server. If it happens to go to the secondary server a bean that
          >has
          >> >> >the correct session data services the request but gives the error
          >> >> ><Failed to update the secondary copy of a stateful session bean
          >from
          >> >> >home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          >> >> >to the primary server will not reflect changes made on the secondary
          >> >> >and vice versa. If the request happens to go to the third server
          >that
          >> >> >is not hosting an instance of that bean then the client receives
          >an
          >> >> >error that the bean was not available. From my understanding I
          >thought
          >> >> >the replica aware stub would know which server is the primary host
          >> >for
          >> >> >that bean and send the request there.
          >> >> >
          >> >> >Thanks in advance,
          >> >> >Justin
          >>
          >
          >

Performance degradation factor 1000 on failover???

          Hi,
          we are gaining first experience with WLS 5.1 EBF 8 clustering on
          NT4 SP 6 workstation.
          We have two servers in the cluster, both on same machine but with
          different IP adresses (as it has to be)!
          In general it seems to work: we have a test client connecting to
          one of the servers and
          uses a stateless test EJB which does nothing but writing into weblogic.log.
          When this server fails, the other server resumes to work the client
          requests, BUT VERY VERY VERY SLOW!!!
          - I should repeat VERY a thousand times, because a normal client
          request takes about 10-30 ms
          and after failure/failover it takes 10-15 SECONDS!!!
          As naive as I am I want to know: IS THIS NORMAL?
          After the server is back, the performance is also back to normal,
          but we were expecting a much smaller
          performance degradation.
          So I think we are doing something totally wrong!
          Do we need some Network solution to make failover performance better?
          Or is there a chance to look closer at deployment descriptors or
          weblogic.system.executeThreadCount
          or weblogic.system.percentSocketReaders settings?
          Thanks in advance for any help!
          Fleming


See http://www.weblogic.com/docs51/cluster/setup.html#680201
          Basically, the rule of thumb is to set the number of execute threads ON
          THE CLIENT to 2 times the number of servers in the cluster and the
          percent socket readers to 50%. In your case with 8 WLS instances in the
          cluster, add the following to the java command line used to start your
          client:
          -Dweblogic.system.executeThreadCount=16
          -Dweblogic.system.percentSocketReaders=50
          Hope this helps,
          Robert
          Fleming Frese wrote:
          > Hi Mike,
          >
          > thanks for your reply.
          >
          > We do not have HTTP clients or Servlets, just EJBs and clients
          > in the same LAN,
          > and the failover should be handled by the replica-aware stubs.
          > So we thought we need no Proxy solution for failover. Maybe we
          > need a DNS to serve failover if this
          > increases our performance?
          >
          > The timeout clue sounds reasonable, but I would expect that the
          > stub times out once and than switches
          > to the other server for subsequent requests. There should be a
          > refresh (after 3 Minutes?) when the stub
          > gets new information about the servers in the cluster, so he could
          > check then if the server is back.
          > This works perfectly with load balancing: If a new server joins
          > the cluster, I automatically receives
          > requests after a while.
          >
          > Fleming
          >
          > "Mike Reiche" <[email protected]> wrote:
          > >
          > >It sounds like every request is first timing out it's
          > >connection
          > >attempt (10 seconds, perhaps?) on the 'down' instance
          > >before
          > >trying the second instance. How do requests 'failover'?
          > >Do you
          > >have Netscape, Apache, or IIS with a wlproxy module? Or
          > >do
          > >you simply have a DNS that takes care of that?
          > >
          > >Mike
          > >
          > >
          > >
          > >"Fleming Frese" <[email protected]> wrote:
          > >>
          > >>Hi,
          > >>
          > >>we are gaining first experience with WLS 5.1 EBF 8 clustering
          > >>on
          > >>NT4 SP 6 workstation.
          > >>We have two servers in the cluster, both on same machine
          > >>but with
          > >>different IP adresses (as it has to be)!
          > >>
          > >>In general it seems to work: we have a test client connecting
          > >>to
          > >>one of the servers and
          > >>uses a stateless test EJB which does nothing but writing
          > >>into weblogic.log.
          > >>
          > >>When this server fails, the other server resumes to work
          > >>the client
          > >>requests, BUT VERY VERY VERY SLOW!!!
          > >> - I should repeat VERY a thousand times, because a normal
          > >>client
          > >>request takes about 10-30 ms
          > >>and after failure/failover it takes 10-15 SECONDS!!!
          > >>
          > >>As naive as I am I want to know: IS THIS NORMAL?
          > >>
          > >>After the server is back, the performance is also back
          > >>to normal,
          > >>but we were expecting a much smaller
          > >>performance degradation.
          > >>
          > >>So I think we are doing something totally wrong!
          > >>Do we need some Network solution to make failover performance
          > >>better?
          > >>Or is there a chance to look closer at deployment descriptors
          > >>or
          > >>weblogic.system.executeThreadCount
          > >>or weblogic.system.percentSocketReaders settings?
          > >>
          > >>Thanks in advance for any help!
          > >>
          > >>Fleming
          > >>
          > >

Can two EARs bind the same ejb?

Hello,
Is it possible to use the same entity bean from different EARs?
I have an entity ejb for the UUP and I want to use the same uup from two different applications, but when the second application is deploying, throws the next exception:
<BEA-149231> <Unable to set the activation state to true for the application 'secondApplicationEAR'.
weblogic.application.ModuleException: Exception activating module: EJBModule(myUUP.jar)
Unable to deploy EJB: MyUUP from myUUP.jar:
[EJB:011008]Unable to bind EJB Home Interface to the JNDI name: ejb.MyUUPRemoteHome.
javax.naming.NameAlreadyBoundException: Failed to bind remote object (ClusterableRemoteRef(605920552248037872S:AdminServer [605920552248037872S
::AdminServer/301])/301 [uup.MyUUPRemoteHome+javax.ejb.EJBHome+weblogic.ejb20.interfaces.RemoteHome]) to replica aware stub
at MyUUPRemoteHome(ClusterableRemoteRef(605920552248037872S::AdminServer [605920552248037872S::AdminServer/300])/300 [u
up.MyUUPRemoteHome+javax.ejb.EJBHome+weblogic.ejb20.interfaces.RemoteHome]); remaining name 'ejb'
at weblogic.rmi.cluster.ClusterableRemoteObject.onBind(ClusterableRemoteObject.java:201)
at weblogic.jndi.internal.BasicNamingNode.bindHere(BasicNamingNode.java:371)
at weblogic.jndi.internal.ServerNamingNode.bindHere(ServerNamingNode.java:140)
at weblogic.jndi.internal.BasicNamingNode.bind(BasicNamingNode.java:317)
at weblogic.jndi.internal.BasicNamingNode.bind(BasicNamingNode.java:324)
at weblogic.jndi.internal.WLEventContextImpl.bind(WLEventContextImpl.java:277)
at weblogic.jndi.internal.WLContextImpl.bind(WLContextImpl.java:407)
at weblogic.ejb.container.deployer.ClientDrivenBeanInfoImpl.activate(ClientDrivenBeanInfoImpl.java:1249)
at weblogic.ejb.container.deployer.EJBDeployer.activate(EJBDeployer.java:1237)
at weblogic.ejb.container.deployer.EJBModule.activate(EJBModule.java:476)
at weblogic.application.internal.flow.ModuleListenerInvoker.activate(ModuleListenerInvoker.java:107)
at weblogic.application.internal.flow.DeploymentCallbackFlow$2.next(DeploymentCallbackFlow.java:411)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
at weblogic.application.internal.flow.DeploymentCallbackFlow.activate(DeploymentCallbackFlow.java:74)
at weblogic.application.internal.flow.DeploymentCallbackFlow.activate(DeploymentCallbackFlow.java:66)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:635)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:16)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:162)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:184)
at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:361)
at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51)
at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:196)
at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
at weblogic.ejb.container.deployer.EJBModule.activate(EJBModule.java:493)
at weblogic.application.internal.flow.ModuleListenerInvoker.activate(ModuleListenerInvoker.java:107)
at weblogic.application.internal.flow.DeploymentCallbackFlow$2.next(DeploymentCallbackFlow.java:411)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
at weblogic.application.internal.flow.DeploymentCallbackFlow.activate(DeploymentCallbackFlow.java:74)
Truncated. see log file for complete stacktrace
I have the myUUP.jar included in the two applications and I working with Weblogic 10.3.
Could you help me?

Now, they are deployed successfully.
I have written distinct names in the <ejb-jndi> property of p13n-profile-config.xml in both applications and I've deleted the <jndi-name> param in weblogic-ejb-jar.xml into my uup jar. It seem is running correctly.
I had a first application EAR that used an uup. The uup is defined in a Ejb Project. In the firstApplication EAR is defined a dependence on the uup.jar. I'm not an expert in uup (that's obvious) and I need other application, with other content manager and other funcionality, but the same autentication and user properties. This is the reason by I defined a second EAR project with dependencies over the same uup.jar that the first EAR project.
But I don´t know if it's the most correct...
Is there a better option?
Thanks for everything.

Replica-aware stub.

Similar Messages

Maybe you are looking for