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.
          >

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 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.

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

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>

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.

Jndi-name javax.naming.NameAlreadyBoundException:

Hi,
I am getting the following error while deploying a CMP Bean. Initially
this started to deploy, but later when I recompiled the source files
and tried to deploy again, I get the following errors.
In fact I am tired of trying to see what's actually happening.
Your immediate response is highly appreciated.
thanks and regards,
F S Joseph
Unable to deploy EJB: country from Country.jar:
weblogic.ejb20.WLDeploymentException: Unable to bind EJB Home
Interface to the JNDI name: ejb.CountryHome. The error was:
javax.naming.NameAlreadyBoundException: Failed to bind remote object
(ClusterableRemoteRef(127.0.0.1
null)/292     [cashnet.ejb.CountryHome+javax.ejb.EJBHome+weblogic.ejb.QueryHome+weblogic.ejb20.interfaces.QueryHandler+weblogic.ejb20.interfaces.RemoteHome])
to replica aware stub at CountryHome(ClusterableRemoteRef(127.0.0.1
[127.0.0.1/291])/291     [cashnet.ejb.CountryHome+javax.ejb.EJBHome+weblogic.ejb.QueryHome+weblogic.ejb20.interfaces.QueryHandler+weblogic.ejb20.interfaces.RemoteHome]);
remaining name 'ejb'
     at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:174)
     at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:262)
     at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:229)
     at weblogic.jndi.internal.ServerNamingNode_WLStub.bind(Unknown
Source)
     at weblogic.jndi.internal.WLContextImpl.bind(WLContextImpl.java:359)
     at weblogic.jndi.internal.WLContextImpl.bind(WLContextImpl.java:353)
     at weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.activate(ClientDrivenBeanInfoImpl.java:951)
     at weblogic.ejb20.deployer.EJBDeployer.activate(EJBDeployer.java:1302)
     at weblogic.ejb20.deployer.EJBModule.activate(EJBModule.java:342)
     at weblogic.j2ee.J2EEApplicationContainer.activateModule(J2EEApplicationContainer.java:1509)
     at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:970)
     at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:957)
     at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(SlaveDeployer.java:1074)
     at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDeployer.java:700)
     at weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHandler.java:24)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
     at weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.activate(ClientDrivenBeanInfoImpl.java:956)
     at weblogic.ejb20.deployer.EJBDeployer.activate(EJBDeployer.java:1302)
     at weblogic.ejb20.deployer.EJBModule.activate(EJBModule.java:342)
     at weblogic.j2ee.J2EEApplicationContainer.activateModule(J2EEApplicationContainer.java:1509)
     at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:970)
     at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:957)
     at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(SlaveDeployer.java:1074)
     at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDeployer.java:700)
     at weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHandler.java:24)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
failed application Country on cashnetserver

there is already an ejb with this name!
this is set in weblogic-ejb-jar.xml
Ronak Parekh wrote:
Unable to deploy EJB: OrganizationEJB from sempire_bc.jar:
Unable to bind EJB Home Interface to the JNDI name: Organization. The error
was:
javax.naming.NameAlreadyBoundException: Organization is already bound;
remaining
name 'com.sempire.builder.business_component'
<<no stack trace available>>

EAR *RE*-deployment failing

I have a simple WL 6.1 setup. One admin server on one box, and a
          cluster of two WL servers on two other boxes. My EAR (wp-dyn.ear)
          contains one JAR (WPNIBeans.jar) and one WAR (WPNI.war) file. When I
          deploy my EAR to the admin server, and then deploy my components to the
          managed server cluster, everything works fine, exactly as it's supposed
          to.
          The problem comes when, without stopping any of the servers, I try to
          re-deploy that EAR file. One of my managed servers consistently works
          fine, and one of my managed servers consistently throws a bunch of
          errors.
          Here's what happens in the managed server that works fine:
          <Aug 27, 2001 3:44:08 PM EDT> <Info> <HTTP> <[HTTP wl6test2] Unloading
          web app: WPNI>
          <Aug 27, 2001 3:44:08 PM EDT> <Info> <HTTP>
          <[WebAppServletContext(2034542,WPNI,/WPNI)] *.jsp: destroy>
          <Aug 27, 2001 3:44:08 PM EDT> <Info> <HTTP>
          <[WebAppServletContext(2034542,WPNI,/WPNI)] *.html: destroy>
          <Aug 27, 2001 3:44:19 PM EDT> <Info> <J2EE> <Undeployed : wp-dyn>
          <Aug 27, 2001 3:44:37 PM EDT> <Info> <EJB> <EJB Deploying file:
          WPNIBeans.jar>
          <Aug 27, 2001 3:44:27 PM EDT> <Info> <EJB> <EJB Deployed EJB with JNDI
          name ...>
          (although I am getting LOTS of <Info> <DGCserver> <Tried to renew lease
          on lost reference: '###'> errors on this server)
          Here's what happens in the managed server that fails to redeploy:
          <Aug 27, 2001 3:44:08 PM EDT> <Info> <HTTP> <[HTTP wl6test2] Unloading
          web app: WPNI>
          <Aug 27, 2001 3:44:08 PM EDT> <Info> <HTTP>
          <[WebAppServletContext(2034542,WPNI,/WPNI)] *.jsp: destroy>
          <Aug 27, 2001 3:44:08 PM EDT> <Info> <HTTP>
          <[WebAppServletContext(2034542,WPNI,/WPNI)] *.html: destroy>
          <Aug 27, 2001 3:44:19 PM EDT> <Info> <J2EE> <Undeployed : wp-dyn>
          <Aug 27, 2001 3:44:37 PM EDT> <Info> <EJB> <EJB Deploying file:
          WPNIBeans.jar>
          <Aug 27, 2001 3:44:38 PM EDT> <Error> <J2EE> <Error deploying
          application wp-dyn:
          Unable to deploy EJB: Interview from WPNIBeans.jar:
          Unable to bind EJB Home Interface to the JNDI name:
          [EJB JNDI name]. 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>>
          >
          <Aug 27, 2001 3:44:38 PM EDT> <Error> <Management>
          <InvocationTargetException setting attribute Deployed on MBean
          common:Location=wl6test2,Name=wp-dyn,Type=ApplicationConfig to value
          true. Method: public void
          weblogic.management.mbeans.custom.Application.setDeployed(boolean)
          throws
          weblogic.management.DeploymentException,weblogic.management.UndeploymentException
          Unable to deploy EJB: Interview from WPNIBeans.jar:
          Unable to bind EJB Home Interface to the JNDI name:
          [EJB JNDI name]. 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>>
          at weblogic.ejb20.deployer.Deployer.deploy(Deployer.java:1011)
          at weblogic.j2ee.EJBComponent.deploy(EJBComponent.java:30)
          at weblogic.j2ee.Application.deploy(Application.java:244)
          at
          weblogic.j2ee.J2EEService.deployApplication(J2EEService.java:183)
          at
          weblogic.management.mbeans.custom.Application.setLocalDeployed(Application.java:360)
          at
          weblogic.management.mbeans.custom.Application.setDeployed(Application.java:294)
          at java.lang.reflect.Method.invoke(Native Method)
          at
          weblogic.management.internal.DynamicMBeanImpl.invokeSetter(DynamicMBeanImpl.java:1313)
          at
          weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:825)
          at
          weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:791)
          at
          weblogic.management.internal.ConfigurationMBeanImpl.setAttribute(ConfigurationMBeanImpl.java:286)
          at
          com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1356)
          at
          com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1331)
          at
          weblogic.management.internal.RemoteMBeanServerImpl_WLSkel.invoke(Unknown
          Source)
          at
          weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:288)
          at
          weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:257)
          at
          weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
          at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          >
          <Aug 27, 2001 3:44:45 PM EDT> <Error> <Cluster> <Conflict start: You
          tried to bind an object under the name
          [EJB JNDI name] in the JNDI tree. The object you have
          bound from [IP Address] is non clusterable and you have tried to bind
          more than once from two or more servers. Such objects can only deployed
          from one server.>
          Here's what happens in the Admin server:
          <Aug 27, 2001 3:44:08 PM EDT> <Info> <HTTP> <[HTTP testserver] Unloading
          web app: WPNI>
          <Aug 27, 2001 3:44:08 PM EDT> <Info> <J2EE> <Undeployed : wp-dyn>
          <Aug 27, 2001 3:44:25 PM EDT> <Info> <EJB> <EJB Deploying file:
          WPNIBeans.jar>
          <Aug 27, 2001 3:44:27 PM EDT> <Info> <EJB> <EJB Deployed EJB with JNDI
          name ...>
          (and so on, but then about the same time the deployment on the bad
          managed server fails, I get this:)
          <Aug 27, 2001 3:44:51 PM EDT> <Error> <HTTP>
          <[WebAppServletContext(2728006,console,/console)] Servlet failed with
          Exception
          weblogic.management.DistributedManagementException: Distributed
          Management [1 exceptions]
          at
          weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBeans(ConfigurationMBeanImpl.java:434)
          at
          weblogic.management.internal.ConfigurationMBeanImpl.setAttribute(ConfigurationMBeanImpl.java:289)
          at
          com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1356)
          at
          com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1331)
          at
          weblogic.management.internal.MBeanProxy.setAttribute(MBeanProxy.java:298)
          at
          weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:180)
          at $Proxy73.setDeployed(Unknown Source)
          at
          weblogic.management.mbeans.custom.ApplicationManager.autoDeploy(ApplicationManager.java:842)
          at
          weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager.java:807)
          at
          weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager.java:701)
          at
          weblogic.management.mbeans.custom.ApplicationManager.update(ApplicationManager.java:198)
          at java.lang.reflect.Method.invoke(Native Method)
          at
          weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:606)
          at
          weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:590)
          at
          weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:350)
          at
          com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
          at
          com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
          at
          weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:444)
          at
          weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:185)
          at $Proxy5.update(Unknown Source)
          at
          weblogic.management.console.webapp._domain.__upload_app._jspService(__upload_app.java:150)
          at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
          at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:263)
          at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
          at
          weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:190)
          at
          weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:112)
          at
          weblogic.management.console.actions.ForwardAction.perform(ForwardAction.java:35)
          at
          weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:172)
          at
          weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:263)
          at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
          at
          weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2390)
          at
          weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:1959)
          at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          --------------- nested within: ------------------
          weblogic.management.configuration.ConfigurationError - with nested
          exception:
          [weblogic.management.DistributedManagementException: Distributed
          Management [1 exceptions]]
          at
          weblogic.management.mbeans.custom.ApplicationManager.autoDeploy(ApplicationManager.java:846)
          at
          weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager.java:807)
          at
          weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager.java:701)
          at
          weblogic.management.mbeans.custom.ApplicationManager.update(ApplicationManager.java:198)
          at java.lang.reflect.Method.invoke(Native Method)
          at
          weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:606)
          at
          weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:590)
          at
          weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:350)
          at
          com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
          at
          com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
          at
          weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:444)
          at
          weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:185)
          at $Proxy5.update(Unknown Source)
          at
          weblogic.management.console.webapp._domain.__upload_app._jspService(__upload_app.java:150)
          at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
          at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:263)
          at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
          at
          weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:190)
          at
          weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:112)
          at
          weblogic.management.console.actions.ForwardAction.perform(ForwardAction.java:35)
          at
          weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:172)
          at
          weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:263)
          at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
          at
          weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2390)
          at
          weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:1959)
          at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          >
          I can't for the life of me figure out why this would work on deployment,
          but not on redeployment, and then only on one of the two managed
          serevrs. Any ideas?
          Thanks,
          - E
          * "A few years ago, when I happened to be out
          * of the country, the top editors at Newsweek
          * called me to tell me that some of the women
          * on the staff had presented them with a
          * petition protesting the unfair treatment of
          * women there. My first reaction was, 'Do you
          * want me to consider the petition, or sign it?'"
          * Katharine Graham, Washington Post (who else?)
          * www.washingtonpost.com/wp-dyn/articles/A29237-2001Jul20.html
          * Erik (Erin) Reid Jones, Chief Architect
          * WashingtonPost.Newsweek Interactive
          * Work: (703) 469-3154
          * Cell: (703) 725-3050
          [att1.html]


Hi,
SharePoint designer may have limited capability on this, you may need to create your workflow using a code.
If you are using a visual studio workflows, you may try to:
Set the IgnoreIfAlreadyExists="False" and ReplaceContent="True" for the WF XAML and Assocaition file in the Elements.xml
Then update the solution with update-spsolution command.
If the workflow changes are not effective, then re-activate the feature on the site.
If should you need help to creating the source codes, you may try to open an advisory ticket regarding this issue.
Best Regards,
Lisa Chen
Forum Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact
[email protected]
Lisa Chen
TechNet Community Support

How to keep track of EJBs in case of failover under clustered environment?

Does anybody know what happens with a stateless session EJB in
weblogic 5.1 under clustered environment, in case of a failover (if
one of computers dies), the one, which keeps that ejb in a pool?
Does that EJB automatically go to the state "does not exist"?
Is method ejbRemove() then called on that EJB?
Or is it still in the "method-ready pool" state? Without ejbCreate()
method being called on this EJB?
Or does it disappear completely without those methods being called on
this EJB?
I need to organize some kind of tracking for those EJBs, and it is
critically important for me to understand what exactly methods are
called on those EJBs.
I saw this, but it does not answer my question:
Clustered EJB
All EJBs are clusterable. If an EJB is deployed on multiple servers in
the cluster, each of these servers will be able to host instances of
the bean. This does not necessarily mean, however, that the bean
instances are clustered.
EJB Homes
All bean homes are clusterable. When a bean is deployed on a server,
its home is bound into the cluster-wide naming service. Because homes
are clusterable, 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 that receives the finds or creates an instance of the bean on
its server.
Stateless EJBs
When a home creates a stateless bean, it returns a replica-aware stub
that can route to any server on which the bean is deployed. Because a
stateless bean holds no state on behalf of the client, the stub is
free to route any call to any server that hosts the bean. Also,
because the bean is clustered, the stub can automatically fail over in
the event of a failure. The stub does not automatically treat the bean
as idempotent, so it will not recover automatically from all failures.
If the bean has been written with idempotent methods, this can be
noted in the deployment descriptor and automatic fail-over will be
enabled in all cases.
Thanks

Check out Java's support for udo/redo: [http://java.sun.com/javase/6/docs/api/javax/swing/undo/package-summary.html]
Also, google the "Memento Pattern".
You don't have to make copies of objects, just maintain commands the can undo and redo your program's state.

Replica aware

Similar Messages

Maybe you are looking for