JNDI replication within a cluster

Hi to all of you,
we successfully enabled HTTP Session replication and tested the failover. We would also like to setup a JNDI replication, so that we can use it as a storage for some shared data -- as stated in http://download.oracle.com/docs/cd/B10464_05/web.904/b10324/cluster.htm this should be enabled automatically, once EJB replication is enabled.
With some problems we finally enabled EJB replication (we configured it through orion-application.xml) and the required replication policy is propagated to our statful beans. Anyway, the JNDI is still not replicated over the machines.
We are running latest OAS 10g, cluster is MultiCast on RedHat Enterprise, replication policy for Stateful beans is set to 'onRequestEnd' (we tried all the options :), our application is normal ear with 1 ejb and 1 war archive and apart from JNDI replication, it works as expected.
Is there some trick that is not mentioned or that we may overlooked in documentation to enable JNDI replication?
Kind Regards,
Martin

Hopefully solved -- though the documentation explicitly mentions rebinding as not working, after any changes made to value stored in JNDI context you should just re-bind the value to the JNDI context; the value is replicated to other JNDI contexts.
m.

Similar Messages

  • JNDI replication in cluster

    Is there a way to force the JNDI replication?
              

    It is on by default, unless you specifically disabled it:
              http://e-docs.bea.com/wls/docs61/javadocs/weblogic/jndi/WLContext.html
              REPLICATE_BINDINGS
              public static final java.lang.String REPLICATE_BINDINGS
              Cluster-specific: Specifies whether tree modifications are replicated
              and is only applicable when connecting to WebLogic Servers that are running
              in a cluster. By default, any modification to the naming tree is replicated
              across the cluster, which ensures that any server can act as a naming server
              for the entire cluster. Setting this property to false changes this behavior
              and should be done with extreme caution: a false setting means that modifications
              to the tree caused by bind, unbind, createSubcontext, and destroySubcontext
              will not be replicated.
              Understand the implications of this property before changing its default (true).
              Pothiraj <[email protected]> wrote:
              > Is there a way to force the JNDI replication?
              Dimitri
              

  • Cluster-wide JNDI replication

    I have a question about cluster wide JNDI replication. I am on weblogic
              7.0 sp2, solaris 8. I have 2 weblogic servers in a cluster and two
              asynchronous JVM's connect to this cluster. The two weblogic servers
              would be w1 and w2 and the JVMs would be j1
              w1 creates a stateful ejb. The handle to this ejb is put on the JNDI
              tree. A JMS message is created which contains the key to the handle
              object. A JMS message is sent which is picked up by one of the JVM's say
              j1. j1 tries to do a lookup of the handle using the key in the JMS
              message and it is not able to find the handle object.
              The reason is that j1 is trying to connect to the w2 to find the handle.
              The change to the jndi tree is not propagated to w2 yet and hence the
              error. Any ideas on why it would take so long to communicate the jndi
              tree? My jndi tree has hardly anything in it. There are a couple of JMS
              connection factories and 3 ejbs and couple of JMS queues.
              Would appreciate any kind of help. I am going to migrate storing the ejb
              handles to another persistent store instead of the jndi tree but till
              then any insight into this problem would be helpful.
              Please don't advice solutions like using Thread.sleep and trying again
              Thanks,
              Shiva.
              

    Shiva,
              > I have a question about cluster wide JNDI replication. I am on weblogic
              > 7.0 sp2, solaris 8. I have 2 weblogic servers in a cluster and two
              > asynchronous JVM's connect to this cluster. The two weblogic servers
              > would be w1 and w2 and the JVMs would be j1
              >
              > w1 creates a stateful ejb. The handle to this ejb is put on the JNDI
              > tree. A JMS message is created which contains the key to the handle
              > object. A JMS message is sent which is picked up by one of the JVM's say
              > j1. j1 tries to do a lookup of the handle using the key in the JMS
              > message and it is not able to find the handle object.
              >
              > The reason is that j1 is trying to connect to the w2 to find the handle.
              > The change to the jndi tree is not propagated to w2 yet and hence the
              > error. Any ideas on why it would take so long to communicate the jndi
              > tree? My jndi tree has hardly anything in it. There are a couple of JMS
              > connection factories and 3 ejbs and couple of JMS queues.
              That's an interesting problem. The handle should have enough information
              to locate the EJB. Are you explicitly trying to connect to W2 from J1 or
              something? That part didn't make sense to me.
              (While it's a different approach, if you need to share data real-time in a
              cluster, use our Coherence Java clustered cache software.)
              Peace,
              Cameron Purdy
              Tangosol, Inc.
              http://www.tangosol.com/coherence.jsp
              Tangosol Coherence: Clustered Replicated Cache for Weblogic
              "Shiva P" <[email protected]> wrote in message
              news:[email protected]...
              >
              

  • JNDI replication\lookup problems

              Hi,
              We have a WL5.1 SP12 cluster that until today consisted of 2 Solaris boxes running
              8 WL instances on the 2.6 OS.
              Today we attempted to add a third Solaris box, running 2 SP12 WL instances on the
              2.8 OS. These two new instances were identical to the other 8 in all respects apart
              from one ejb jar which they did not deploy (because of Solaris 2.8\JNI\JDK1.3.1 incompatiblilities).
              We figured that these new JVM could lookup this bean via the clustered JNDI and execute
              on one of the original 8 JVMs, so we did not deploy on these new servers. This worked
              fine on test (a 3 way cluster, on one box running Solaris 2.8 and SP10).
              However when we cut the new box in this morning we got javax.naming.NameNotFoundExceptions
              from the new JVMs.
              These new JVMs apeared to start fine, and everything looked as it should on the console,
              but still the error.
              so :
              what could it be :
              OS related - a clustering spanning 2.6 and 2.8 OSs
              SP 12 related ?
              Anybody encountered anything like this before ?
              Thanks in advance.
              Justin
              

              Yes, the EJB classes are in the server classpath.
              I assumed that JNDI replication occured as a resulting of enabling clustering.
              "Sabha" <[email protected]> wrote:
              >Are the ejb home/remote interfaces in the server classpath of the 2 newer
              >JVMs? Is jndi replication turned off?
              >
              >-Sabha
              >
              >"Justin" <[email protected]> wrote in message
              >news:[email protected]...
              >>
              >> Hi,
              >>
              >> We have a WL5.1 SP12 cluster that until today consisted of 2 Solaris boxes
              >running
              >> 8 WL instances on the 2.6 OS.
              >>
              >> Today we attempted to add a third Solaris box, running 2 SP12 WL instances
              >on the
              >> 2.8 OS. These two new instances were identical to the other 8 in all
              >respects apart
              >> from one ejb jar which they did not deploy (because of Solaris
              >2.8\JNI\JDK1.3.1 incompatiblilities).
              >> We figured that these new JVM could lookup this bean via the clustered
              >JNDI and execute
              >> on one of the original 8 JVMs, so we did not deploy on these new servers.
              >This worked
              >> fine on test (a 3 way cluster, on one box running Solaris 2.8 and SP10).
              >>
              >> However when we cut the new box in this morning we got
              >javax.naming.NameNotFoundExceptions
              >> from the new JVMs.
              >>
              >> These new JVMs apeared to start fine, and everything looked as it should
              >on the console,
              >> but still the error.
              >>
              >> so :
              >>
              >> what could it be :
              >>
              >> OS related - a clustering spanning 2.6 and 2.8 OSs
              >> SP 12 related ?
              >>
              >> Anybody encountered anything like this before ?
              >>
              >> Thanks in advance.
              >>
              >> Justin
              >>
              >>
              >>
              >
              >
              

  • Event structure to detect value change of a control within a cluster in an array

    I have 1D array that contains a cluster. The cluster contains a numeric and a boolean control.
    If the user starts to edit the numeric control value i would like to call one subVI, and if the boolean control value is changed, call a different subVI.
    The array control on the front panel allows the user to edit a number of the array elements. 
    I would like to use an event structure to detect a value change in the cluster. When editing the Events, in the Event Sources panel i get the option to select only the array, not the cluster within the array or the controls within the cluster. Can the Event structure be opened up to show controls within clusters and arrays?
    The solution i am using is to detect a mouse up event on the array and then use property nodes to  determine if the key focus is on the numeric, and  a case structure to determine which subVI to call. This works, but is there a better (simpler) way?
    Thanks, Blue.

    Thanks for the responses guys.
    The tricky bit was that i wanted the numeric control values to flag they were going to be edited, so i could call a subVI, before their values were changed by the user. This is done by using the key focus property node, - i need to detect changes on the fly rather than post the event.  Probably didn't make this clear enough in my original post. 
    The array is of variable size depending on if the user decides to insert or delete elements. The user also has the option to click and edit the array without having to do to much scrolling through the array index, as the FP shows several elements at a time. The Event Structure does a good job of automatically determining which element in the array is being edited, and returning those values to the property nodes. Turned out simpler than i thought it might be at one point!
    Cheers, Blue. 
    Message Edited by BlueTwo on 01-15-2009 06:52 AM
    Attachments:
    evstrct1.jpg ‏63 KB

  • RetrieveJXM metrics from within the cluster?

    I would like to know if it is possible to retrieve the metrics the JMX adapter exposes from within the cluster e.g. by running a thread on the invocation service that would query the underlying data structures to get the metrics out.

    You could still snapshot the stats if you wanted to but you would have to do it using queries into the local JMS server running in the JVM rather than using Coherence API calls.
    Or, depending on what you want to do with the stats, you could look at the JMX reporter that will log stats to a file every so often or you could look at one of the third-party monitoring tolls that will do this.
    JK

  • How is index data managed within the cluster?

    Hello
    We are in the process of evaluating Coherence.
    With regard to indexes, am I correct in thinking that the data for the index is stored in an (internally managed) cache on the same node as the attendant indexed values? I'm not interested in getting at the index data, but rather just understanding how the index data itself is treated/stored within the cluster.
    So in a 2 node cluster where an index is applied to a distributed cache that only has 2 entries, will there be an index cache on each node that has 1 {Binary,key} entry where the key points to the value that is stored on that same node? That is, I trust that the index data is spread out across the cluster in the case of a partitioned topology?
    Regards
    Peter

    user11279467 wrote:
    Hello
    We are in the process of evaluating Coherence.
    With regard to indexes, am I correct in thinking that the data for the index is stored in an (internally managed) cache on the same node as the attendant indexed values? I'm not interested in getting at the index data, but rather just understanding how the index data itself is treated/stored within the cluster.
    So in a 2 node cluster where an index is applied to a distributed cache that only has 2 entries, will there be an index cache on each node that has 1 {Binary,key} entry where the key points to the value that is stored on that same node? That is, I trust that the index data is spread out across the cluster in the case of a partitioned topology?
    Regards
    PeterHi Peter,
    up to 3.4.x indexes were supported only on partitioned topology, and yes, indexes on each node contain only data corresponding to entries which have their primary copy on that node (referred to as local entries from now on).
    The indexes are not stored in a cache but they are managed as part of the information Coherence maintains about the backing map (the map which contains local entries).
    The indexes are made of 2 parts:
    - forward index: this is a mapping from the cache key in an internal representation (backing map keys from now on) to the value extracted with the extractor used to create the index from the entry belonging to the cache key (extracted value from now on)
    - reverse index (aka. reverse map): this is a mapping from the extracted value to a set of backing map keys of entries from which the reverse index key was extracted with the extractor used to create the index
    The index can be sorted which means that the reverse index will be a SortedMap (so sorting order is the ordering of extracted values)
    Let's see an example. Assuming you have the following cache content within a particular storage-enabled node :
    A --> Object (getX=5 ,...)
    B --> Object (getA=3 ,...)
    C --> Object (getA=3 ,...)
    D --> Object (getA=4 ,...)
    The forward index in that node will contain:
    Binary(A) --> 5
    Binary(B) --> 3
    Binary(C) --> 3
    Binary(D) --> 4
    The reverse index will contain:
    3 --> { Binary(B), Binary(C) }
    4 --> { Binary(D) }
    5 --> { Binary(A) }
    Where Binary(...) means the internal (binary) representation of the ... object.
    If the index is not ordered, then the order of iteration on entries in the reverse index are not deterministic.
    If the index is ordered, then the iteration of entries in the reverse index will be as shown above. Also, you can cast the reverse index to SortedMap so you have the very useful headMap and tailMap and firstKey and lastKey methods.
    Hope this helps.
    Best regards,
    Robert

  • Http session replication fails in cluster

    Hello everybody.
    I have some problems with HTTP session replication in WebLlogic cluster environment. I have a cluster with 2 nodes and application deployed there. Application is configured with:
    <session-param>
    <param-name>PersistentStoreType</param-name>
    <param-value>replicated</param-value>
    </session-param>
    in weblogic.xml
    WebLogic plug-in for Apache webserver is configured properly as described in documentation.
    But when I try to make experiment to enter the application, make some activities, look in console where I was redirected by apache proxy and manually shut down the node where request was sent, I loose my HTTP session with all data there (all the beans stored in session are Serializable). Replication doesn't work correctly. May be I've missed something in configuration? How can I configure my application to provide correctness session replication?
    Thanks for advice.
    Thanks

    Thanks for response!
    I'm using WebLogic 8.1 SP 4 and configured Apache proxy as described in documentation for load balancing. The only section I have in httpd.conf is next:
    <Location /HTTPClnt>
         SetHandler weblogic-handler
    </Location>
    <IfModule mod_weblogic.c> 
         WebLogicCluster serv1:7541,serv2:7541
         MatchExpression *.*
         Debug ON 
         WLLogFile /www/tmp/global_proxy.log  
         WLTempDir "/www/tmp" 
         DebugConfigInfo On 
         KeepAliveEnabled ON 
         KeepAliveSecs  15
    </IfModule>
    <Location /myApp> 
         SetHandler weblogic-handler
         WebLogicCluster serv1:7541,serv2:7541
    </Location>and the string to include weblogic proxy module for apache:
    LoadModule weblogic_module     modules/mod_wl_20.soI've configured CookiesEnabled=true in weblogic.xml, but it didn't help. About session specification in httpd.conf - where can I read about that? I've just configured apache according to manual from here:
    [url http://e-docs.bea.com/wls/docs92/plugins/apache.html]http://e-docs.bea.com/wls/docs92/plugins/apache.html
    Thanks

  • JNDI replication problems in WebLogic cluster.

    I need to implement a replicable property in the cluster: each server could
    update it and new value should be available for all cluster. I tried to bind
    this property to JNDI and got several problems:
    1) On each rebinding I got error messages:
    <Nov 12, 2001 8:30:08 PM PST> <Error> <Cluster> <Conflict start: You tried
    to bind an object under the name example.TestName in the jndi tree. The
    object you have bound java.util.Date from 10.1.8.114 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.>
    <Nov 12, 2001 8:30:18 PM PST> <Error> <Cluster> <Conflict Resolved:
    example.TestName for the object java.util.Date from 10.1.9.250 under the
    bind name example.TestName in the jndi tree.>
    As I understand this is a designed behavior for non-RMI objects. Am I
    correct?
    2) Replication is still done, but I got randomly results: I bind object to
    server 1, get it from server 2 and they are not always the same even with
    delay between operation in several seconds (tested with 0-10 sec.) and while
    it lookup returns old version after 10 sec, second attempt without delay
    could return correct result.
    Any ideas how to ensure correct replication? I need lookup to return the
    object I bound on different sever.
    3) Even when lookup returns correct result, Admin Console in
    Server->Monitoring-> JNDI Tree shows an error for bound object:
    Exception
    javax.naming.NameNotFoundException: Unable to resolve example. Resolved: ''
    Unresolved:'example' ; remaining name ''
    My configuration: admin server + 3 managed servers in a cluster.
    JNDI bind and lookup is done from stateless session bean. Session is
    clusterable and deployed to all servers in cluster. Client invokes session
    methods throw t3 protocol directly on servers.
    Thank you for any help.

    It is not a good idea to use JNDI to replicate application data. Did you consider
    using JMS for this? Or JavaGroups (http://sourceforge.net/projects/javagroups/) -
    there is an example of distibuted hashtable in examples.
    Alex Rogozinsky <[email protected]> wrote:
    I need to implement a replicable property in the cluster: each server could
    update it and new value should be available for all cluster. I tried to bind
    this property to JNDI and got several problems:
    1) On each rebinding I got error messages:
    <Nov 12, 2001 8:30:08 PM PST> <Error> <Cluster> <Conflict start: You tried
    to bind an object under the name example.TestName in the jndi tree. The
    object you have bound java.util.Date from 10.1.8.114 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.>
    <Nov 12, 2001 8:30:18 PM PST> <Error> <Cluster> <Conflict Resolved:
    example.TestName for the object java.util.Date from 10.1.9.250 under the
    bind name example.TestName in the jndi tree.>
    As I understand this is a designed behavior for non-RMI objects. Am I
    correct?
    2) Replication is still done, but I got randomly results: I bind object to
    server 1, get it from server 2 and they are not always the same even with
    delay between operation in several seconds (tested with 0-10 sec.) and while
    it lookup returns old version after 10 sec, second attempt without delay
    could return correct result.
    Any ideas how to ensure correct replication? I need lookup to return the
    object I bound on different sever.
    3) Even when lookup returns correct result, Admin Console in
    Server->Monitoring-> JNDI Tree shows an error for bound object:
    Exception
    javax.naming.NameNotFoundException: Unable to resolve example. Resolved: ''
    Unresolved:'example' ; remaining name ''
    My configuration: admin server + 3 managed servers in a cluster.
    JNDI bind and lookup is done from stateless session bean. Session is
    clusterable and deployed to all servers in cluster. Client invokes session
    methods throw t3 protocol directly on servers.
    Thank you for any help.--
    Dimitri

  • How to create InitialContext for JNDI lookup in a cluster?

              I am new to clusters in WL7 and I wanted to know how a client would create an InitialContext
              object to perform a JNDI lookup for a remote object deployed across serveral servers
              in the cluster. Is the following correct?
              Physcial Servers in the cluster
              machine1:9001
              machine2:9001
              machine3:9001
              Code for creating InitialContext
              Properties p = new Properties();
              p.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
              p.put(Context.PROVIDER_URL, "machine1:9001,machine2:9001,machine3:9001");
              Context c = new InitialContext( p);
              Thanks,
              Raffi
              

    Hi Ivaylo,
    There's another alternative solution to your problem. You can have the screen 120 as a user-defined selection screen. i.e., instead of creating this screen through the screen painter, you can create it from within your ABAP Program. This way, you can directly use the SELECT-OPTIONS statement within your screen. You then will no longer have to bother about how to handle the data for the field.
    Especially in the case where your screen 120 has few elements, this approach, in my opinion, will be the best.
    Please let me know if you need any further clarifications on how to go about it if you choose to follow this approach.
    Regards,
    Anand Mandalika.

  • Clustered jndi replication

    Does the replication in clustered jndi also support removing replicate
    bindings
    when you call unbind()?
    When I programmatically bind a value (a String), it is replicated throughout
    the cluster but when I try to unbind it only gets removed on one server.
    Calling rebind with a new value doesn't work either; a message is printed to
    the console saying there is a conflict. Has anyone seen this before and/or
    is there
    something I'm missing.
    This is on weblogic5.1sp4.

    This sounds like a bug.
    I suggest that you file a bug report with our support organization. Be sure
    to include a complete test case. They will also need information from
    you -- please review our external support procedures:
    http://www.beasys.com/support/index.html
    Thanks,
    Michael
    Michael Girdley
    BEA Systems Inc
    "Jonathon Lee" <[email protected]> wrote in message
    news:398b4219$[email protected]..
    Does the replication in clustered jndi also support removing replicate
    bindings
    when you call unbind()?
    When I programmatically bind a value (a String), it is replicatedthroughout
    the cluster but when I try to unbind it only gets removed on one server.
    Calling rebind with a new value doesn't work either; a message is printedto
    the console saying there is a conflict. Has anyone seen this beforeand/or
    is there
    something I'm missing.
    This is on weblogic5.1sp4.

  • JNDI lookup in a cluster

    Hi,
              The WL documentation contains the following:
              "When clients obtain an initial JNDI context by supplying the cluster DNS
              name, weblogic.jndi.WLInitialContextFactory obtains the list of all
              addresses that are mapped to the DNS name"
              Should clients (e.g. an EJB) be concerned about retrying the call to get the
              Initial Context. In other words, can this call fail if one of the servers in
              the cluster fails?
              After the intital contect is obtained, it seems that the lookup should
              always work (since WL will take care of individual server failures and retry
              the lookup in needed).
              Not clear whether the call to get the initial context is guaranteed to
              succeed (as long as one server in the cluster is up, of course)... Any
              information would be appreciated.
              Thanks,
              Philippe
              

              Hello Philippe,
              I had posted a similar question but now can't find it...got lost I suppose. Anyway,
              I wanted to add in my findings on this. I have a stateful session object running
              in a clustered setup. This stateful object has Home references to multiple stateless
              beans. When I create a failover my stateful object does its failover properly.
              But, if I don't perform a new Home lookup for the stateless objects needed I receive
              the following error:
              ####<Nov 9, 2001 2:00:06 PM CST> <Error> <> <gwiz> <testServer1> <ExecuteThread:
              '9' for queue: 'default'> <> <> <000000> <<TestDeliveryActionHandler>Problem occured
              when trying to do a save and goto. java.rmi.NoSuchObjectException: Activation
              failed with: java.rmi.NoSuchObjectException: Unable to locate EJBHome: 'GBTestManagerHome'
              on server: 't3://10.1.17.3:7001
              When I perform a lookup during the ejbactivate() method to get a new Home reference
              all seems to work OK. My question though is, is this correct? From what I have
              read I had the same impression that the unserialized Home reference should be
              able to locate a new reference in the cluster without having to perform a lookup
              again.
              Any advice from anyone is greatly appreciated,
              Rich
              "Philippe Fajeau" <[email protected]> wrote:
              >Hi,
              >
              >The WL documentation contains the following:
              >
              >"When clients obtain an initial JNDI context by supplying the cluster
              >DNS
              >name, weblogic.jndi.WLInitialContextFactory obtains the list of all
              >addresses that are mapped to the DNS name"
              >
              >Should clients (e.g. an EJB) be concerned about retrying the call to
              >get the
              >Initial Context. In other words, can this call fail if one of the servers
              >in
              >the cluster fails?
              >
              >After the intital contect is obtained, it seems that the lookup should
              >always work (since WL will take care of individual server failures and
              >retry
              >the lookup in needed).
              >
              >Not clear whether the call to get the initial context is guaranteed to
              >succeed (as long as one server in the cluster is up, of course)... Any
              >information would be appreciated.
              >
              >Thanks,
              >
              >Philippe
              >
              >
              

  • Loading the JNDI Tree in a Cluster

    Is there any special processing that occurs with a Startup class when it
              has been
              started via the cluster level properties file?
              We've got a class that loads the JNDI tree for various configuration for
              our application.
              It's written that so that it will rebind() entries in the tree, so two
              copies could work together
              in the cluster, but I'd like to prevent the double work. (One copy
              bind()s an element, then the other rebind()s the same value.
              Are Startups "cluster" aware, and is there any magic to simplify this
              for me (or do I do the
              work of creating a semaphore-like setup in my class to detect two copies
              running.)
              Thanks in Advance,
              Brian Homrich
              Chicago, Illinois
              

    In the startup class on Environment object if you don't set
              replicatebindings to false, in a cluster all locally bound objects will be
              replicated. The default it true. So, jndi will try replicate every
              bind/rebind etc.
              Rebind will remove old copy and bind the new copy. But I have to understand
              more what you are trying to do, before I can be of any help.
              - Prasad
              Brian Homrich wrote:
              > Is there any special processing that occurs with a Startup class when it
              > has been
              > started via the cluster level properties file?
              >
              > We've got a class that loads the JNDI tree for various configuration for
              > our application.
              > It's written that so that it will rebind() entries in the tree, so two
              > copies could work together
              > in the cluster, but I'd like to prevent the double work. (One copy
              > bind()s an element, then the other rebind()s the same value.
              >
              > Are Startups "cluster" aware, and is there any magic to simplify this
              > for me (or do I do the
              > work of creating a semaphore-like setup in my class to detect two copies
              > running.)
              >
              > Thanks in Advance,
              >
              > Brian Homrich
              > Chicago, Illinois
              

  • JNDI cache in a Cluster

    Lets say that we have 2 machines in a cluster, If I cache in the JNDI, which
              is accessible from both Servers,
              1. when they update the same cache then how can we put a lock so that they
              don't mess up other user's data.
              2. Can I hide this cache for the other machine in the cluster?.
              3. What is the best way to do session level caching?. For Example, If I use
              the sessionID of the Weblogic's HttpSession, It is too big to store it.
              4. What is the maximum objects can be stored in the JNDI? If I store 400-500
              objects in the JNDI , whether performance will be affected?!
              5. Do I have to rebind cache if I update the data?
              Thanks
              /selvan
              Captura Software Inc
              

    Lets say that we have 2 machines in a cluster, If I cache in the JNDI, which
              is accessible from both Servers,
              1. when they update the same cache then how can we put a lock so that they
              don't mess up other user's data.
              2. Can I hide this cache for the other machine in the cluster?.
              3. What is the best way to do session level caching?. For Example, If I use
              the sessionID of the Weblogic's HttpSession, It is too big to store it.
              4. What is the maximum objects can be stored in the JNDI? If I store 400-500
              objects in the JNDI , whether performance will be affected?!
              5. Do I have to rebind cache if I update the data?
              Thanks
              /selvan
              Captura Software Inc
              

  • Replication in a Cluster of 2 machines

    Hi again,
              I have a cluster of 2 m/c , Requests are being served by A and I bring A
              Down
              'B' takes over , but when I bring up A again , both fail !
              I need some help !
              The Stack traces on A and B are :
              The Stack on A is :
              ++++++++++++++++
              <Jul 31, 2002 5:00:15 PM PDT> <Error> <HTTP Session> <Error looking up
              session for id:9I4trxgFdltJ7Yzz3YjvhEPJd1A5XnlCPm
              4nzIwGny1sytuNGPMT!-388044873!167772203!7001!7002!NONE
              java.lang.NullPointerException:
              Start server side stack trace:
              java.lang.NullPointerException
              at
              weblogic.servlet.internal.session.SessionData.getContext(SessionData.java:34
              1)
              at
              weblogic.servlet.internal.session.ReplicatedSessionData.becomeSecondary(Repl
              icatedSessionData.java:167)
              at weblogic.cluster.replication.WrappedRO.<init>(WrappedRO.java:34)
              at
              weblogic.cluster.replication.ReplicationManager$wroManager.create(Replicatio
              nManager.java:352)
              at
              weblogic.cluster.replication.ReplicationManager.create(ReplicationManager.ja
              va:1083)
              at weblogic.cluster.replication.ReplicationManager_WLSkel.invoke(Unknown
              Source)
              at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
              at
              weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
              at
              weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
              2)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              End server side stack trace
              at
              weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.
              java:85)
              at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:136)
              at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
              at $Proxy152.create(Unknown Source)
              at
              weblogic.cluster.replication.ReplicationManager.trySecondary(ReplicationMana
              ger.java:880)
              at
              weblogic.cluster.replication.ReplicationManager.createSecondary(ReplicationM
              anager.java:835)
              at
              weblogic.cluster.replication.ReplicationManager.getPrimary(ReplicationManage
              r.java:799)
              at
              weblogic.cluster.replication.ReplicationManager.lookup(ReplicationManager.ja
              va:425)
              at
              weblogic.servlet.internal.session.ReplicatedSessionContext.getSessionInterna
              l(ReplicatedSessionContext.java:2
              68)
              at
              weblogic.servlet.internal.ServletRequestImpl.getValidSession(ServletRequestI
              mpl.java:2186)
              at
              weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.j
              ava:1948)
              at
              weblogic.servlet.security.ServletAuthentication.weak(ServletAuthentication.j
              ava:266)
              at
              weblogic.servlet.security.internal.BasicSecurityModule.checkAuthenticateHead
              er(BasicSecurityModule.java:65)
              at
              weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(Servle
              tSecurityManager.java:119)
              at
              weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
              ntext.java:2518)
              at
              weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
              :2260)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              >
              At B its :
              ++++++
              <Jul 31, 2002 5:00:18 PM PDT> <Warning> <Dispatcher> <RuntimeException
              thrown by
              rmi server: 'weblogic.rmi.internal.BasicServerRef@10 - jvmid:
              '3432093889910090
              597S:10.0.0.33:[7001,7001,7002,7002,7001,7002,-1]:admindomain:server2', oid:
              '16
              ', implementation: 'weblogic.cluster.replication.ReplicationManager@398fe1''
              java.lang.NullPointerException
              at
              weblogic.servlet.internal.session.SessionData.getContext(SessionData.
              java:341)
              at
              weblogic.servlet.internal.session.ReplicatedSessionData.becomeSeconda
              ry(ReplicatedSessionData.java:167)
              at weblogic.cluster.replication.WrappedRO.<init>(WrappedRO.java:34)
              at
              weblogic.cluster.replication.ReplicationManager$wroManager.create(Rep
              licationManager.java:352)
              at
              weblogic.cluster.replication.ReplicationManager.create(ReplicationMan
              ager.java:1083)
              at
              weblogic.cluster.replication.ReplicationManager_WLSkel.invoke(Unknown
              Source)
              at
              weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
              at
              weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.jav
              a:274)
              at
              weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest
              .java:22)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              >
              

    I hope you are right,
              But its no longer a problem for me after I changed the stuff..
              Thanks though,
              _NR
              "Kumar Allamraju" <[email protected]> wrote in message
              news:[email protected]...
              > First of all the following NPE has nothing to do with using
              > weblogic.servlet.proxy.HttpClusterServlet or
              > weblogic.servlet.internal.HttpClusterServlet. For backward compatibility
              > purposes you can still use weblogic.servlet.internal.HttpClusterServlet
              >
              > The following NPE is a known issue in SP2 and is fixed in SP3.
              >
              > --
              > Kumar
              >
              > [email protected] wrote:
              >
              > > hmmm....
              > >
              > > Again figured it out myself..
              > >
              > > I was using the (depreicated)
              weblogic.servlet.internal.HttpClusterServlet
              > > in the web.xml (Default app for Admin)
              > >
              > > I changed it to weblogic.servlet.proxy.HttpClusterServlet and everythin
              > > works fine !!
              > >
              > > thought this info might be useful !
              > >
              > > --Naggi
              > > PS: Now running WLS 6.1 SP3 with CR081194_61sp3.jar
              > >
              > >
              > >
              > >
              > > <[email protected]> wrote in message
              news:[email protected]...
              > >
              > >>Hi again,
              > >>I have a cluster of 2 m/c , Requests are being served by A and I bring
              A
              > >>Down
              > >>'B' takes over , but when I bring up A again , both fail !
              > >>
              > >>I need some help !
              > >>
              > >>The Stack traces on A and B are :
              > >>
              > >>The Stack on A is :
              > >>++++++++++++++++
              > >><Jul 31, 2002 5:00:15 PM PDT> <Error> <HTTP Session> <Error looking up
              > >>session for id:9I4trxgFdltJ7Yzz3YjvhEPJd1A5XnlCPm
              > >>4nzIwGny1sytuNGPMT!-388044873!167772203!7001!7002!NONE
              > >>
              > >>java.lang.NullPointerException:
              > >>
              > >>Start server side stack trace:
              > >>
              > >>java.lang.NullPointerException
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.servlet.internal.session.SessionData.getContext(SessionData.java:34
              > >
              > >>1)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.servlet.internal.session.ReplicatedSessionData.becomeSecondary(Repl
              > >
              > >>icatedSessionData.java:167)
              > >>
              > >>at weblogic.cluster.replication.WrappedRO.<init>(WrappedRO.java:34)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.cluster.replication.ReplicationManager$wroManager.create(Replicatio
              > >
              > >>nManager.java:352)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.cluster.replication.ReplicationManager.create(ReplicationManager.ja
              > >
              > >>va:1083)
              > >>
              > >>at weblogic.cluster.replication.ReplicationManager_WLSkel.invoke(Unknown
              > >>Source)
              > >>
              > >>at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
              > >
              > >>at
              > >>
              > >>
              > >
              weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
              > >
              > >>2)
              > >>
              > >>at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              > >>
              > >>at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              > >>
              > >>End server side stack trace
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.
              > >
              > >>java:85)
              > >>
              > >>at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:136)
              > >>
              > >>at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
              > >>
              > >>at $Proxy152.create(Unknown Source)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.cluster.replication.ReplicationManager.trySecondary(ReplicationMana
              > >
              > >>ger.java:880)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.cluster.replication.ReplicationManager.createSecondary(ReplicationM
              > >
              > >>anager.java:835)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.cluster.replication.ReplicationManager.getPrimary(ReplicationManage
              > >
              > >>r.java:799)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.cluster.replication.ReplicationManager.lookup(ReplicationManager.ja
              > >
              > >>va:425)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.servlet.internal.session.ReplicatedSessionContext.getSessionInterna
              > >
              > >>l(ReplicatedSessionContext.java:2
              > >>
              > >>68)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.servlet.internal.ServletRequestImpl.getValidSession(ServletRequestI
              > >
              > >>mpl.java:2186)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.j
              > >
              > >>ava:1948)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.servlet.security.ServletAuthentication.weak(ServletAuthentication.j
              > >
              > >>ava:266)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.servlet.security.internal.BasicSecurityModule.checkAuthenticateHead
              > >
              > >>er(BasicSecurityModule.java:65)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(Servle
              > >
              > >>tSecurityManager.java:119)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
              > >
              > >>ntext.java:2518)
              > >>
              > >>at
              > >>
              > >>
              > >
              weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
              > >
              > >>:2260)
              > >>
              > >>at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              > >>
              > >>at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              > >>
              > >>
              > >>
              > >>At B its :
              > >>++++++
              > >>
              > >><Jul 31, 2002 5:00:18 PM PDT> <Warning> <Dispatcher> <RuntimeException
              > >>thrown by
              > >> rmi server: 'weblogic.rmi.internal.BasicServerRef@10 - jvmid:
              > >>'3432093889910090
              > >>597S:10.0.0.33:[7001,7001,7002,7002,7001,7002,-1]:admindomain:server2',
              > >>
              > > oid:
              > >
              > >>'16
              > >>', implementation:
              > >>
              > > 'weblogic.cluster.replication.ReplicationManager@398fe1''
              > >
              > >>java.lang.NullPointerException
              > >> at
              > >>weblogic.servlet.internal.session.SessionData.getContext(SessionData.
              > >>java:341)
              > >> at
              > >>weblogic.servlet.internal.session.ReplicatedSessionData.becomeSeconda
              > >>ry(ReplicatedSessionData.java:167)
              > >> at
              > >>
              > > weblogic.cluster.replication.WrappedRO.<init>(WrappedRO.java:34)
              > >
              > >> at
              > >>weblogic.cluster.replication.ReplicationManager$wroManager.create(Rep
              > >>licationManager.java:352)
              > >> at
              > >>weblogic.cluster.replication.ReplicationManager.create(ReplicationMan
              > >>ager.java:1083)
              > >> at
              > >>weblogic.cluster.replication.ReplicationManager_WLSkel.invoke(Unknown
              > >> Source)
              > >> at
              > >>weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
              > >> at
              > >>weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.jav
              > >>a:274)
              > >> at
              > >>weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest
              > >>.java:22)
              > >> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              > >> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              > >>
              > >>
              > >>
              > >>
              > >>
              > >>
              > >>
              > >
              > >
              >
              

Maybe you are looking for