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

Similar Messages

  • 6140 Replication Problem in Sun Cluster

    Hi,
    I am not able to mount a replicate volume from cluster system (primary site) to non-cluster system (DR site). Replication was done by 6140 storage. In primary site the volume was configured in a system with metaset under Solaris Cluster 3.2. and in DR site it was mapped in a non-cluster system after suspending the replication.
    I even tried to mount the volume in DR site (non-cluster system) by creating a metaset and putting the volume under this and mount it from there. But this action also not working.
    Following are the log of the errors:
    drserver # mount -F ufs /dev/dsk/c3t600A0B80004832A600002D554B74AC56d0s0 /mnt/
    mount: /dev/dsk/c3t600A0B80004832A600002D554B74AC56d0s0 is not this fstype
    drserver #
    drserver #
    drserver #
    drserver #
    drserver # fstyp -v /dev/dsk/c3t600A0B80004832A600002D554B74AC56d0s0
    Unknown_fstyp (no matches)
    drserver #
    I will be grateful if you have any workaround for this. Please note that, the replication from the non-cluster system is working fine. Only from the cluster system it is not working and showing above errors.

    I am not sure how you can run Solaris 10 Update 8, since to my knowledge that is not released.
    What is available is Solaris 10 05/09, which would be Update 7.
    You are not describing what exact problem you have (like specific error messages you see), or what exactly you did to end up in the situation you have.
    I would recommend to open a support case to get a more structured analysis of your problem.
    Regards
    Thorsten

  • Session lost problem in Weblogic cluster and Iplanet proxy

              We have an environment like this
              Iplanet 4.1--> Two Weblogic servers.(WLS 6.1 sp1)
              The Weblogic servers are not really clusterd, but we are using the Weblogic Cluster
              attribute in the obj.conf to configure the proxy (The Weblogic servers are really
              independant servers with the same application deployed).
              This is working fine in our development environment. No problem with session and
              load balancing. Although this architecture is not documented in Weblogic docs,
              I have seen several references to this type of architecture in the web and it
              seems to be working.
              Now we are into our pre-production environment. The same archictecture exists.
              Only the following differences
              1. Both the weblogic servers run on multihomed machines. We have bound the Weblogic
              servers to specific IP addresses using the Listen address option.
              2. The same IP addresses are there in the proxy plug-in conf file.
              3. There is a firewall between the Iplanet and Weblogic.
              Now if only one weblogic is running, the application works fine. The moment we
              turn the other weblogic on, the application starts misbehaving. The session seems
              to get lost and proxy forwards requests randomly.
              What could be the reason?
              Regards
              Anup
              

              Hi
              The problem got solved. There was an older version of libproxy.so in the Iplanet
              proxy
              Regards
              Anup
              Yeshwant Kamat <[email protected]> wrote:
              >Anup,
              >
              >Is there a reason you are not clustering the WLS instances? Remove the
              >firewall in your
              >prod environment and see if that makes a difference.
              >
              >Anup wrote:
              >
              >> Hi Mike
              >> 1. As per the documentation WebLogic Server is set up to handle session
              >tracking
              >> by default. So we are not doing anything special. Since the application
              >works
              >> fine with one Weblogic and multiple clients connecting to it through
              >Iplanet ,
              >> I think there is no problem with Session tracking as such.
              >>
              >> 2.We are using the default cookie name for session (JSESSIONID). So
              >we haven't
              >> done anything extra in the proxy set up or weblogic.xml
              >>
              >> 3. I have watched the cookie that comes on the browser
              >> PAACk3iviDm4ZuMPIbB9TpTTw9slk40IEC02MKjpu14EZ9ayzqaP!-1196227542!gmbpds054!7015!7016.
              >>
              >> gmbpds054 is the DNS name of one of the weblogic servers. So that is
              >also fine.
              >>
              >> What else could be the problem.
              >> Regards
              >> Anup
              >>
              >> "Mike Reiche" <[email protected]> wrote:
              >> >
              >> >If you have session tracking turned on in weblogic, creating a session
              >> >will write
              >> >a cookie back to the browser. iPlanet does sticky load balancing
              >based
              >> >on the
              >> >IP address in this cookie. So -
              >> >
              >> >1) do you have session tracking turned on?
              >> >
              >> >2) is the cookie getting written to your browser?
              >> >
              >> >3) are iPlanet and WebLogic using the same cookie? (same name)
              >> >
              >> >Mike
              >> >
              >> >"Anup Maliyackel" <[email protected]> wrote:
              >> >>
              >> >>We have an environment like this
              >> >>
              >> >>Iplanet 4.1--> Two Weblogic servers.(WLS 6.1 sp1)
              >> >>
              >> >>The Weblogic servers are not really clusterd, but we are using the
              >Weblogic
              >> >>Cluster
              >> >>attribute in the obj.conf to configure the proxy (The Weblogic servers
              >> >>are really
              >> >>independant servers with the same application deployed).
              >> >>
              >> >>This is working fine in our development environment. No problem with
              >> >>session and
              >> >>load balancing. Although this architecture is not documented in Weblogic
              >> >>docs,
              >> >>I have seen several references to this type of architecture in the
              >web
              >> >>and it
              >> >>seems to be working.
              >> >>
              >> >>Now we are into our pre-production environment. The same archictecture
              >> >>exists.
              >> >>Only the following differences
              >> >>1. Both the weblogic servers run on multihomed machines. We have
              >bound
              >> >>the Weblogic
              >> >>servers to specific IP addresses using the Listen address option.
              >> >>
              >> >>2. The same IP addresses are there in the proxy plug-in conf file.
              >> >>
              >> >>3. There is a firewall between the Iplanet and Weblogic.
              >> >>
              >> >>Now if only one weblogic is running, the application works fine.
              >The
              >> >>moment we
              >> >>turn the other weblogic on, the application starts misbehaving. The
              >> >session
              >> >>seems
              >> >>to get lost and proxy forwards requests randomly.
              >> >>
              >> >>What could be the reason?
              >> >>
              >> >>Regards
              >> >>Anup
              >> >
              >
              

  • Jndi lookup problem between weblogic 6.1 and 8.1

    Hello,
    I have a portal application running in weblogic 6.1(sp2). It needs to lookup a
    Stateless Session Bean which is deployed in Weblogic 8.1.
    I have the 8.1 version ejb client jar in my WEB-INF/lib
    Here is my code:
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.TengahInitialContextFactory");
    env.put(Context.PROVIDER_URL, "t3://server1.abc.com:port);
    ctx = new InitialContext(env);
    Object objref = ctx.lookup(EJBJNDI_NAME);
    mEJBHome = (EJBServiceHome)PortableRemoteObject.narrow(objref, EJBServiceHome.class);
    mEJBService=mEJBHome.create();
    An exception occurred during the ctx.lookup call:
    javax.naming.CommunicationException. Root exception is java.rmi.UnmarshalException:
    Problem finding error class; nested exception is:
    java.lang.ClassNotFoundException: java.lang.StackTraceElement
    java.lang.ClassNotFoundException: java.lang.StackTraceElement
    at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClass
    Loader.java:180)
    at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAw
    areClassLoader.java:68)
    What troubles me is that the exact same code worked for a regular web application
    (web1.war), but not the portal application (portal1.war). Both web1.war and portal1.war
    are inside app.ear
    Please help!! Any guess/suggestions are welcome.
    Thank you!
    Ellen

    Hi,
    All I can say is Weblogic6.1 doesnot use JDK1.4 compared to Weblogic8.1, hence the class java.lang.StackTraceElement is not found when the object is executed in 6.1.
    This is clue which you may like to take forward for debugging your application.
    Thanks.

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

  • 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
              

  • Session state replication taking time to replicate in weblogic cluster

    I have a application fully serialized code with WEB-INF/lib containing the below configs with Unicast communication.
    <?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">
    <weblogic-web-app>
      <session-descriptor>
        <session-param>
          <param-name>TimeoutSecs</param-name>
          <param-value>1800</param-value>
        </session-param>
                    <cookie-http-only>false</cookie-http-only>
      <persistent-store-type>replicated_if_clustered</persistent-store-type>
                    </session-descriptor>
    </weblogic-web-app>
    OHS plugin is having below config
    LoadModule weblogic_module   "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"
    <IfModule mod_weblogic.c>
    WebLogicCluster 172.12.113.141:7006,172.12.113.140:7006
            MatchExpression /finapp/*
    </IfModule>
    And weblogic cluster is replicating session instantly when ever there is some activities happening in the application.
    It is having a problem only in below scenario when the session is open but the user is not doing anything.
    I have 2 nodes in the cluster if one goes down(currently request serving one) it is failing over to the next but the session is not getting copied instantly. Below is the scenario where it works fine and where the replication is delayed.
    1. Both servers(server1,server2) up for some time and user logs in and is continuing work.
    2. primary server(server1) crashes in middle, secondary(server2) will take over the existing session and you will see user will be continuing the work without any issues(no logouts).
    3. After sometime server1 comes up online, user keeps on testing(clicking some tab which makes a request to server), you will see the server1 will have a replica of server2 instantly.
    4. You can bring down the server2 now and you will see the users session will not interrupt and user will be able to continue session with the server1.
    Now coming to the scenario where you will be able to delayed replication :
    1. Both servers up and user logged in and started work.
    2. Primary server(server1) goes down and secondary server(server2) will take over the session and let the user continue its work without any logout.
    2. server1 comes back online and user is not doing anything(no clicks) with application just kept the session open and server2(primary session) goes down within the replication time then the user will get logged out and might see some erratic behavior in any applications deployed to that weblogic. (We saw that if we dont shutdown server2 immediately(within 1min) and wait for 5mins+ weblogic is copying  the session from server2 to server1. After that copy if we shutdown the primary server(server2) user is not having any issues)
    To summerize if a session is active(logged in) and some activity(clicking) is going on then replication is happening instantly from primary to secondary but if the user is active(logged in) and not doing anything(not clicking) then the session from primary to secondary is taking 5minutes+
    Please let me know if there is some weblogic configs to check to reduce this time lag and let weblogic copy the session continuously either the user is performing any activity or not in the logged in session.
    Thanks,

    Hi,
    This is the expected behavior. Please take a look at this document: WebLogic Server - Session Replication/Failover Scenario When Only One Server In Cluster is RUNNING (Doc ID 1292033.1)
    In a WebLogic Server domain, with a Cluster of 2 Managed Servers and a web application deployed on this Cluster, you have only one managed server running and then you make a request through a proxy server to access the application.
    The default cookie which is JSESSIONID will be created something like
    <SessionID>!<PrimaryJVMID>!NONE
    Here, you see the secondary server as NONE as there is only one server in cluster running.
    Now, you leave HTTP session idle, meaning there will be no activity and requests in it.
    Now, you bring up the second managed server instance in the cluster. The JSESSIONID for the earlier created HTTPSession will be unchanged: still
    <SessionID>!<PrimaryJVMID>!NONE
    unless there are any requests made or activity in it.
    At this point of time, if there is a failure of the Managed server, the idle in-flight HTTP Sessions which were created earlier when this managed server was RUNNING, will be dropped and there will be no failover. Only active HTTP Sessions which have a secondary JVM ID will be failed over to the secondary managed server.
    At any point, if subsequent requests are made and if any activity is made to the Idle HTTP sessions which were earlier created, the JSESSIONID gets updated with the secondary JVMID and sessions gets replicated and failed over in case of server crash.

  • Problems with WebLogic in-memory replication

    We are using Netscape Server 4.0 with the WebLogic 4.51sp7 proxy connecting
              to 2 clustered machines. We'd like to use the in-memory replication, but
              whenever we set up our weblogic.properties file like the description in the
              "Setting up a WebLogic Cluster" document, we get an error. The following
              are the settings we are setting:
              weblogic.httpd.clustering.enable=true
              weblogic.httpd.session.persistence=true
              webloigc.httpd.session.persistentStoreType=replicated
              We get the error when we try to start up any of the servers in the cluster.
              The following is the error:
              Unable to initialize server: java.lang.NullPointerException
              fatal initialization exception
              java.lang.NullPointerException
              at weblogic.t3.srvr.HttpServer.start(Compiled Code)
              at weblogic.t3.srvr.T3Srvr.start(Compiled Code)
              at weblogic.t3.srvr.T3Srvr.main(Compiled Code)
              at weblogic.Server.startServerDynamically(Compiled Code)
              at weblogic.Server.main(Compiled Code)
              Any information anyone has out there would be greatly appreciated!
              

    Actually, it is just the weblogic.httpd.clustering.enable=true that causes
              problems. When I remove it, it starts up just fine, but I don't think it is
              using the in-memory replication. It is throwing the exception near the end
              of the start up procedure, just after loading the EJBs. Lately, it hasn't
              even been throwing the exception, it just hangs. The last lines we see are:
              74 EJBs were deployed using .ser files.
              0 EJBs were deployed using .jar files
              It is at this point that it either throws the exception or hangs. We do
              have clustering licenses for all the machines in the cluster. We are using
              the default multicastAddress (237.0.0.1) so I was not explicitly setting it.
              Now, I am and it doesn't seem to make any difference.
              Any ideas?
              John
              "Mike Benham" <[email protected]> wrote in message
              news:[email protected]...
              >
              > So just setting those listed properties causes an NPE? If you remove
              > just those properties, you don't get an NPE? At what point in the
              > startup procedure is that exception thrown? Although it shouldn't
              > result in that error, are you sure that you have a clustering license?
              > You also need to set the multicast address to use for your cluster:
              > weblogic.cluster.multicastAddress=IP.
              >
              > - Mike
              >
              >
              > John Peters wrote:
              > >
              > > We are using Netscape Server 4.0 with the WebLogic 4.51sp7 proxy
              connecting
              > > to 2 clustered machines. We'd like to use the in-memory replication,
              but
              > > whenever we set up our weblogic.properties file like the description in
              the
              > > "Setting up a WebLogic Cluster" document, we get an error. The
              following
              > > are the settings we are setting:
              > >
              > > weblogic.httpd.clustering.enable=true
              > > weblogic.httpd.session.persistence=true
              > > webloigc.httpd.session.persistentStoreType=replicated
              > >
              > > We get the error when we try to start up any of the servers in the
              cluster.
              > > The following is the error:
              > >
              > > Unable to initialize server: java.lang.NullPointerException
              > > fatal initialization exception
              > > java.lang.NullPointerException
              > > at weblogic.t3.srvr.HttpServer.start(Compiled Code)
              > > at weblogic.t3.srvr.T3Srvr.start(Compiled Code)
              > > at weblogic.t3.srvr.T3Srvr.main(Compiled Code)
              > > at weblogic.Server.startServerDynamically(Compiled Code)
              > > at weblogic.Server.main(Compiled Code)
              > >
              > > Any information anyone has out there would be greatly appreciated!
              

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

  • Session in-memory replication problem

    Hi,
              I am running into some cluster HttpSession replication problems. Here is
              the scenario where replication fails (all servers mentioned here are a
              part of a cluster).
              1a - 2 Weblogic servers (A&B) are running - no users logged in,
              2a - user logs in and a new session in server A is created.
              3a - after several interactions, server A is killed.
              4a - after user makes susequent request, Weblogic correctly fails over
              to server B
              Problem: Not entire session data is replicated. The authentication info
              seems to
              be replicated correctly but there are some collections in the session of
              server A
              that did not make it to the session in server B.
              The interesting part is this: If there is only one server A running to
              begin with and a user
              interacts with it for a while and only then server B is started, when
              after server B starts up
              server A dies - the entire session (which is exactly the same as in the
              failing scenario) is
              corretly replicated in B, including collections that were missing in the
              failing scenario.
              How can this be possible ????
              Thanks for any info on this one - it really puzzles me.
              Andrew
              

    Yes, you are on the right track. Everytime you modify the object you should call
              putValue. We will make it more clear in the docs.
              - Prasad
              Andrzej Porebski wrote:
              > Everything is Serilizable. I get no exceptions. I did however read some old
              > posts regarding
              > session replication and I hope I found an answer. It basically seems to boil
              > down to what
              > triggers session sync-up between servers. In my case , I store an object into
              > session and
              > later on manipulate that object directly wihotu session involvment and the
              > results of those manipulations
              > are not replicated - no wonder if HttpSession's putValue method is the only
              > trigger.
              > Am i on the right track here?
              >
              > -Andrew
              >
              > Prasad Peddada wrote:
              >
              > > Do you have non serializable data by any chance?
              > >
              > > - Prasad
              > >
              > > Andrzej Porebski wrote:
              > >
              > > > Hi,
              > > > I am running into some cluster HttpSession replication problems. Here is
              > > > the scenario where replication fails (all servers mentioned here are a
              > > > part of a cluster).
              > > > 1a - 2 Weblogic servers (A&B) are running - no users logged in,
              > > > 2a - user logs in and a new session in server A is created.
              > > > 3a - after several interactions, server A is killed.
              > > > 4a - after user makes susequent request, Weblogic correctly fails over
              > > > to server B
              > > >
              > > > Problem: Not entire session data is replicated. The authentication info
              > > > seems to
              > > > be replicated correctly but there are some collections in the session of
              > > > server A
              > > > that did not make it to the session in server B.
              > > >
              > > > The interesting part is this: If there is only one server A running to
              > > > begin with and a user
              > > > interacts with it for a while and only then server B is started, when
              > > > after server B starts up
              > > > server A dies - the entire session (which is exactly the same as in the
              > > > failing scenario) is
              > > > corretly replicated in B, including collections that were missing in the
              > > > failing scenario.
              > > >
              > > > How can this be possible ????
              > > >
              > > > Thanks for any info on this one - it really puzzles me.
              > > >
              > > > Andrew
              > >
              > > --
              > > Cheers
              > >
              > > - Prasad
              >
              > --
              > -------------------------------------------------------------
              > Andrzej Porebski
              > Sailfish Systems, Ltd. Phone 1 + (212) 607-3061
              > 44 Wall Street, 17th floor Fax: 1 + (212) 607-3075
              > New York, NY 10005
              > -------------------------------------------------------------
              

  • Weblogic cluster for 24x7 environment and a front OHS server

    Hi experts,
    We are going to set up a reliable J2EE application server environment by using clustering webgoic servers on TWO nodes, and a front OHS https server in DMZ for load balancing.
    I am new to weblogic cluster and load balance by OHS. I have visited this forum for Fusion MiddleWare clustering etc. Can some experts share some light on this?
    Will our deployment architecture be able to handle the J2EE applications failover? In other word, we can restart one of Weblogic Managed Servers when a new release of J2EE codes are re-deployed without impacting business end users’s usage?
    Problems we want to solve:
    1. All J2EE applications are available for 24x7 even when new J2EE codes are released and deployed on weblogic Managed Servers ANY TIME, side-by-side deployment and restart a managed server if we need to clean the HTTP cache.
    2. The J2EE applications should be accessed by external and internal users with a Single Access Point, like
    https://apps.company1.com/j2ee1
    https://apps.company2.com/j2ee1
    https://apps.company1.com/j2ee2
    https://apps.company2.com/j2ee2
    All J2EE applications (j2ee1, j2ee2, j2ee3 etc) should be deployed on both of weblogic Servers in a cluster, and pointing to a SAME backend database.
    Can some experts share with us the best practices on components and configurations? Thanks.

    Seems your architecture is like Browser => OHS ( DMZ ) => Weblogic => DB OR Browser => HLB( like bigip ) => OHS ( DMZ ) => Weblogic => DB
    Cluster is the solution for load balancing however if you are using OHS for redirection to weblogic then OHS does the load balancing in round robin way. using cluster in this way has a benefit of in case of any one of your managed server is down the OHS will divert connection request to any one of the active managed server ( you have to turn on dynamic list on at OHS ).
    http://weblogicserveradministration.blogspot.com/2010/10/load-balancing-in-weblogic-server.html
    Failover is something different, if in case any of the any managed server goes down then your user you get the application session from another server but new one, means the the tasks not saved by the users on earlier session will lost. for that yo need to use cluster and then need to enable the session replication. another best option is you can use the coherence web if you are using latest versions of weblogic supporting coherence web. with that you not need to worry on user sessions and you can start any of the managed server anytime without worrying about the user sessions.
    http://weblogicserveradministration.blogspot.com/2010/10/manage-http-session-states-session.html
    http://weblogicserveradministration.blogspot.com/2011/05/oracle-coherence-37-coherenceweb.html
    http://weblogicserveradministration.blogspot.com/2010/11/clustering-part-i.html
    another way is, you can use side by side deployment feature in case you don't want shutdown your application completely, with this, old connections and new requests will goes to old application and once new application activated all new requests will come to new application and once all requests on old application will complete that application will retire automatically.
    Regards
    Mukesh Negi
    http://weblogicserveradministration.blogspot.com

  • StreamCorruptedException when starting Weblogic cluster

    Hi, I have an application running on Weblogic Server 8.1 sp4 in clustered environment. When the cluster is restarted the first server restarts without errors but the second one has the following error message. What does the error message mean? Some messages have disappeared form the JMS queue when the cluster has been restarted. Does this error message have something to do with the disappeared messages?
              <29.9.2006 14:09:17 EEST> <Notice> <Cluster> <BEA-000138> <Listening for announcements from cluster Cluster2 on 237.0.0.6:10603.>
              <29.9.2006 14:09:17 EEST> <Notice> <Cluster> <BEA-000133> <Waiting to synchronize with other running members of Cluster2.>
              <29.9.2006 14:09:47 EEST> <Notice> <Cluster> <BEA-000142> <Trying to download cluster JNDI tree from server CL2Server2.>
              <29.9.2006 14:09:54 EEST> <Error> <JMS> <BEA-040368> <The following exception has occurred:
              java.io.StreamCorruptedException: Unknown object stream version. 5505025
                   at weblogic.jms.store.BufferDataInputStream.readObject(BufferDataInputStream.java:167)
                   at weblogic.jms.store.JDBCIOStream.doRecoverBodies(JDBCIOStream.java:1024)
                   at weblogic.jms.store.JDBCIOStream.doRecover(JDBCIOStream.java:939)
                   at weblogic.jms.store.JDBCIOStream.recover(JDBCIOStream.java:1140)
                   at weblogic.jms.store.JMSStore.recover(JMSStore.java:315)
                   at weblogic.jms.backend.BEStore.open(BEStore.java:264)
                   at weblogic.jms.backend.BEStore.start(BEStore.java:151)
                   at weblogic.jms.backend.BackEnd.openStores(BackEnd.java:1171)
                   at weblogic.jms.backend.BackEnd.resume(BackEnd.java:1290)
                   at weblogic.jms.backend.BackEnd.migratableActivate(BackEnd.java:2939)
                   at weblogic.cluster.migration.MigratableGroup.add(MigratableGroup.java:107)
                   at weblogic.cluster.migration.MigrationManager.privateRegister(MigrationManager.java:180)
                   at weblogic.cluster.migration.MigrationManager.register(MigrationManager.java:127)
                   at weblogic.jms.JMSService.addJMSServer(JMSService.java:2226)
                   at weblogic.jms.JMSService.addDeployment(JMSService.java:2031)
                   at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:337)
                   at weblogic.management.mbeans.custom.DeploymentTarget.addDeployments(DeploymentTarget.java:597)
                   at weblogic.management.mbeans.custom.DeploymentTarget.updateServerDeployments(DeploymentTarget.java:575)
                   at weblogic.management.mbeans.custom.DeploymentTarget.updateDeployments(DeploymentTarget.java:241)
                   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                   at java.lang.reflect.Method.invoke(Method.java:324)
                   at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:754)
                   at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:733)
                   at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:509)
                   at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1560)
                   at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1528)
                   at weblogic.management.internal.RemoteMBeanServerImpl.private_invoke(RemoteMBeanServerImpl.java:988)
                   at weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:946)
                   at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:954)
                   at weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:481)
                   at weblogic.management.configuration.ServerMBean_Stub.updateDeployments(ServerMBean_Stub.java:7691)
                   at weblogic.management.deploy.slave.SlaveDeployer.updateServerDeployments(SlaveDeployer.java:1304)
                   at weblogic.management.deploy.slave.SlaveDeployer.resume(SlaveDeployer.java:347)
                   at weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.resume(DeploymentManagerServerLifeCycleImpl.java:229)
                   at weblogic.t3.srvr.SubsystemManager.resume(SubsystemManager.java:131)
                   at weblogic.t3.srvr.T3Srvr.resume(T3Srvr.java:966)
                   at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:361)
                   at weblogic.Server.main(Server.java:32)

    Make sure that the JMS server isn't attempting to load a store that was created from a later version of WLS. Also, make sure that no two JMS servers share the same database table - otherwise they will corrupt each-other's data. I think the latter is likely the problem.
              Tom

  • Problems with weblogic clustering in 6.1 sp3

    We have spent a lot of time trying to get our application deployed to
              a cluster using weblogic 6.1 sp3 and we consistently receive a failure
              when we attempt to start the managed server. This was not a problem
              with weblogic sp1--we got our application to deploy to the cluster
              successfully; although there was another weblogic bug there with
              clients accessing EJB clusters--we won't go into that here...
              We have tried this on both a Windows 2000 machine and an HP machine
              running weblogic sp3. The same error occurs on both platforms.
              The error in deploying our application to the cluster against weblogic
              sp3 looks to have to do with our custom security realm. Inside our
              custom realm we make use of a configurable providerUrl which we set to
              the cluster address/port. The custom realm makes a call where it
              passes in the providerUrl to:
                   weblogic.management.Helper.getMBeanHome(..., providerUrl,...)
              When we have our providerUrl set to the cluster address/port--e.g.,
                   t3://clustermember1:7001
              and attempt to start the managed server we get the error:
              Starting WebLogic Server ....
              Connecting to http://adminserver:7117...
              The WebLogic Server did not start up properly.
              Exception raised:
              weblogic.management.configuration.ConfigurationException:
              clustermember1 not found
                   at weblogic.management.Admin.getBootstrapLocalServer(Admin.java:1084)
                   at weblogic.management.Admin.initialize(Admin.java:340)
                   at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:359)
                   at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:206)
                   at weblogic.Server.main(Server.java:35)
              Reason: Fatal initialization exception
              When we have our providerUrl set to the admin server address--e.g.,
                   t3://adminserver:7117
              everything starts up fine.
              Does anyone know why this would work on sp1 and not sp3 of weblogic
              6.1?
              We verified that all passwords are correct and everything else we
              could determine--any ideas would be helpful.
              We don't want the providerUrl to point at our admin server, we want it
              to point at the cluster address/port.
              When we get the managed server error, we received this error on the
              AdminServer:
              2002-08-15 16:52:23,019 ERROR [ExecuteThread: '11' for queue:
              'default'] (com.msa.gabriel.share.security.wlrealm.GabrielRealm) -
              Caught naming exception null; throwing RuntimeException.
              javax.naming.CommunicationException. Root exception is
              java.net.ConnectException: t3://tomtate.msais.com:7119: Destination
              unreachable; nested exception is:
                   java.net.ConnectException: Connection refused; No available router to
              destination
                   at weblogic.rjvm.RJVMFinder.findOrCreate(RJVMFinder.java:155)
                   at weblogic.rjvm.ServerURL.findOrCreateRJVM(ServerURL.java:207)
                   at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:307)
                   at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:211)
                   at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:149)
                   at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:665)
                   at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246)
                   at javax.naming.InitialContext.init(InitialContext.java:222)
                   at javax.naming.InitialContext.<init>(InitialContext.java:198)
                   at com.msa.gabriel.share.security.wlrealm.GabrielRealm.getNamingContext(GabrielRealm.java:416)
                   at com.msa.gabriel.share.security.wlrealm.GabrielRealm.getConnection(GabrielRealm.java:347)
                   at com.msa.gabriel.share.security.wlrealm.GabrielRealm.access$000(GabrielRealm.java:51)
                   at com.msa.gabriel.share.security.wlrealm.GabrielRealm$2.run(GabrielRealm.java:225)
                   at weblogic.security.acl.Security.doAsPrivileged(Security.java:489)
                   at com.msa.gabriel.share.security.wlrealm.GabrielRealm.myDoAsPrivileged(GabrielRealm.java:578)
                   at com.msa.gabriel.share.security.wlrealm.GabrielRealm.getUser(GabrielRealm.java:221)
                   at weblogic.security.acl.CachingRealm.getUserEntry(CachingRealm.java:832)
                   at weblogic.security.acl.CachingRealm.getUser(CachingRealm.java:696)
                   at weblogic.security.acl.Security.getCurrentUser(Security.java:250)
                   at weblogic.servlet.security.internal.SecurityModule.auditPerm(SecurityModule.java:356)
                   at weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(ServletSecurityManager.java:205)
                   at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.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)
              <Aug 15, 2002 4:52:23 PM EDT> <Error> <HTTP>
              <[WebAppServletContext(8091823,wl_management_internal2,/wl_management_internal2)]
              Servlet failed with Exception
              java.lang.RuntimeException
                   at com.msa.gabriel.share.security.wlrealm.GabrielRealm.getUser(GabrielRealm.java:260)
                   at weblogic.security.acl.CachingRealm.getUserEntry(CachingRealm.java:832)
                   at weblogic.security.acl.CachingRealm.getUser(CachingRealm.java:696)
                   at weblogic.security.acl.Security.getCurrentUser(Security.java:250)
                   at weblogic.servlet.security.internal.SecurityModule.auditPerm(SecurityModule.java:356)
                   at weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(ServletSecurityManager.java:205)
                   at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.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)
              Thanks for any help.
              Rich
              

    Bottom line:
              In our custom realm we were not handling user guest correctly. Even if you
              have guest user disabled, Weblogic seems to have hard-coded guest to
              send messages to the cluster every-so-often. Not sure there--couldn't get
              an answer out of bea as to exactly why we see guest still being used...
              It seems that with sp3, the user guest interaction started happening earlier
              than it did with sp1, consequently making our realm code fail when trying to
              retrieve the guest user like someone we knew about in our system.
              Hence, our getUser and authUserPassword methods now return null for both
              users guest and system, making the secondary realm (file realm) be used to
              authenticate and resolve guest & system. BEA helped get our code fixed;
              however, we still don't have a lot of depth in understanding Weblogic
              server's use of guest...
              Apparently, in 7.x the guest & system user behavior and configuration is
              different also... We'll see when we start digging into that migration.
              Rich
              [email protected] (Rich Koch) wrote in message news:<[email protected]>...
              > Thanks for the responses--we're working with weblogic support now. We
              > think that the custom realm that we have [the developer that wrote it
              > left the company] is the problem.
              >
              > The original developer was told by someone to check:
              > weblogic.security.acl.internal.ClusterRealm.THE_ONE != null
              >
              > In order to determine if the JNDI was available/ready for the whole
              > cluster.
              >
              > It seems that the meaning/setting of THE_ONE changed with this respect
              > from
              > sp1 to sp3--i.e., this is no longer a valid test to tell us if the
              > JNDI is
              > ready for the cluster.
              >
              > We believe this was used because the 'system' user has to be
              > authenticated before the custom realm is up. Originally, before this
              > check was in place, an exception was received when authenticating
              > 'system'. This appears to be a weblogic limitation/issue. Support
              > has told us that this is different in weblogic 7.0. Unfortunately, we
              > can't upgrade from 6.1 yet.
              >
              > We'll post the solution when this gets figured out.
              >
              > Rak
              >
              > "Sabha" <[email protected]> wrote in message news:<[email protected]>...
              > > There was a security restriction enforced from sp2/sp3 onwards in terms of
              > > looking up mbeans from admin server.
              > >
              > > This might cause things to fail if you are attempting to lookup Mbeans with
              > > guest priviliges from admin server. Also, can you try doing the following:
              > >
              > > Run " java weblogic.Admin -url adminServer -username system -password
              > > .... -GET -pretty -type Server" and check whether the named clustermember1
              > > is available in the list or not.
              > >
              > > Also you seem to be getting some security exception - can you check that.
              > >
              > > t3://tomtate.msais.com:7119: Destination
              > > unreachable; nested exception is:
              > >
              > > --- Try running weblogic.Admin PING on this one and see whether you are
              > > able to reach this server upon the error message.
              > >
              > > --Sabha
              > >
              > > "Rich Koch" <[email protected]> wrote in message
              > > news:[email protected]...
              > > > We have spent a lot of time trying to get our application deployed to
              > > > a cluster using weblogic 6.1 sp3 and we consistently receive a failure
              > > > when we attempt to start the managed server. This was not a problem
              > > > with weblogic sp1--we got our application to deploy to the cluster
              > > > successfully; although there was another weblogic bug there with
              > > > clients accessing EJB clusters--we won't go into that here...
              > > >
              > > > We have tried this on both a Windows 2000 machine and an HP machine
              > > > running weblogic sp3. The same error occurs on both platforms.
              > > >
              > > > The error in deploying our application to the cluster against weblogic
              > > > sp3 looks to have to do with our custom security realm. Inside our
              > > > custom realm we make use of a configurable providerUrl which we set to
              > > > the cluster address/port. The custom realm makes a call where it
              > > > passes in the providerUrl to:
              > > > weblogic.management.Helper.getMBeanHome(..., providerUrl,...)
              > > >
              > > > When we have our providerUrl set to the cluster address/port--e.g.,
              > > > t3://clustermember1:7001
              > > >
              > > > and attempt to start the managed server we get the error:
              > > >
              > > > Starting WebLogic Server ....
              > > > Connecting to http://adminserver:7117...
              > > >
              > ***************************************************************************
              > > > The WebLogic Server did not start up properly.
              > > > Exception raised:
              > > > weblogic.management.configuration.ConfigurationException:
              > > > clustermember1 not found
              > > > at weblogic.management.Admin.getBootstrapLocalServer(Admin.java:1084)
              > > > at weblogic.management.Admin.initialize(Admin.java:340)
              > > > at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:359)
              > > > at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:206)
              > > > at weblogic.Server.main(Server.java:35)
              > > > Reason: Fatal initialization exception
              > > >
              > ***************************************************************************
              > > >
              > > > When we have our providerUrl set to the admin server address--e.g.,
              > > > t3://adminserver:7117
              > > >
              > > > everything starts up fine.
              > > >
              > > > Does anyone know why this would work on sp1 and not sp3 of weblogic
              > > > 6.1?
              > > > We verified that all passwords are correct and everything else we
              > > > could determine--any ideas would be helpful.
              > > >
              > > > We don't want the providerUrl to point at our admin server, we want it
              > > > to point at the cluster address/port.
              > > >
              > > > When we get the managed server error, we received this error on the
              > > > AdminServer:
              > > >
              > > > 2002-08-15 16:52:23,019 ERROR [ExecuteThread: '11' for queue:
              > > > 'default'] (com.msa.gabriel.share.security.wlrealm.GabrielRealm) -
              > > > Caught naming exception null; throwing RuntimeException.
              > > > javax.naming.CommunicationException. Root exception is
              > > > java.net.ConnectException: t3://tomtate.msais.com:7119: Destination
              > > > unreachable; nested exception is:
              > > > java.net.ConnectException: Connection refused; No available router to
              > > > destination
              > > > at weblogic.rjvm.RJVMFinder.findOrCreate(RJVMFinder.java:155)
              > > > at weblogic.rjvm.ServerURL.findOrCreateRJVM(ServerURL.java:207)
              > > > at
              > > weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialCon
              > > textFactoryDelegate.java:307)
              > > > at
              > > weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialCon
              > > textFactoryDelegate.java:211)
              > > > at
              > > weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFact
              > > ory.java:149)
              > > > at
              > javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:665)
              > > > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246)
              > > > at javax.naming.InitialContext.init(InitialContext.java:222)
              > > > at javax.naming.InitialContext.<init>(InitialContext.java:198)
              > > > at
              > > com.msa.gabriel.share.security.wlrealm.GabrielRealm.getNamingContext(Gabriel
              > > Realm.java:416)
              > > > at
              > > com.msa.gabriel.share.security.wlrealm.GabrielRealm.getConnection(GabrielRea
              > > lm.java:347)
              > > > at
              > > com.msa.gabriel.share.security.wlrealm.GabrielRealm.access$000(GabrielRealm.
              > > java:51)
              > > > at
              > > com.msa.gabriel.share.security.wlrealm.GabrielRealm$2.run(GabrielRealm.java:
              > > 225)
              > > > at weblogic.security.acl.Security.doAsPrivileged(Security.java:489)
              > > > at
              > > com.msa.gabriel.share.security.wlrealm.GabrielRealm.myDoAsPrivileged(Gabriel
              > > Realm.java:578)
              > > > at
              > > com.msa.gabriel.share.security.wlrealm.GabrielRealm.getUser(GabrielRealm.jav
              > > a:221)
              > > > at weblogic.security.acl.CachingRealm.getUserEntry(CachingRealm.java:832)
              > > > at weblogic.security.acl.CachingRealm.getUser(CachingRealm.java:696)
              > > > at weblogic.security.acl.Security.getCurrentUser(Security.java:250)
              > > > at
              > > weblogic.servlet.security.internal.SecurityModule.auditPerm(SecurityModule.j
              > > ava:356)
              > > > at
              > > weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(Servle
              > > tSecurityManager.java:205)
              > > > 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)
              > > > <Aug 15, 2002 4:52:23 PM EDT> <Error> <HTTP>
              > > >
              > > <[WebAppServletContext(8091823,wl_management_internal2,/wl_management_intern
              > > al2)]
              > > > Servlet failed with Exception
              > > > java.lang.RuntimeException
              > > > at
              > > com.msa.gabriel.share.security.wlrealm.GabrielRealm.getUser(GabrielRealm.jav
              > > a:260)
              > > > at weblogic.security.acl.CachingRealm.getUserEntry(CachingRealm.java:832)
              > > > at weblogic.security.acl.CachingRealm.getUser(CachingRealm.java:696)
              > > > at weblogic.security.acl.Security.getCurrentUser(Security.java:250)
              > > > at
              > > weblogic.servlet.security.internal.SecurityModule.auditPerm(SecurityModule.j
              > > ava:356)
              > > > at
              > > weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(Servle
              > > tSecurityManager.java:205)
              > > > 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)
              > > >
              > > >
              > > > Thanks for any help.
              > > >
              > > > Rich
              

  • Weblogic cluster OIM 10g - "Edit workflow" selection does not show anything

    Hello,
    My setup is OIM 10g (9102 BP15) in WLS cluster.
    When i login as a administrator and click on "Resource Management" -> Manage -> chose a resource -> "Resource workflow" (from drop down) -> "Edit workflow" on approval/provisioning flows, a new window pops up. However, it doesn't open any workflow details in the GUI. When i click "Done" (IE Yellow Triangle) on the bottom left corner of the IE window and copy the error details, it is:
    =============================================================================
    Webpage error details:
    User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
    Timestamp: Mon, 6 Feb 2012 22:30:33 UTC
    Message: 'Is' is undefined
    Line: 207
    Char: 5
    Code: 0
    URI: http://<hostname>/xlWebApp/richclientlauncher.jsp?app=xlWebApp/loadDesignWorkflow.do?method=LoadWorkflow&processName=<chosen+resource>
    Message: Object expected
    Line: 30
    Char: 6
    Code: 0
    URI: http://<hostname>/xlWebApp/richclientlauncher.jsp?app=xlWebApp/loadDesignWorkflow.do?method=LoadWorkflow&processName=<chosen+resource>
    =============================================================================
    On the other hand, if i click on
    "Resource Management" -> Manage -> chose a resource -> "Resource workflow" (from drop down) -> "Configure" (Form Data Flow/Reconciliation Data Flow). I see below errors in the log:
    =====================================
    <Feb 7, 2012 10:56:48 AM PST> <Error> <Cluster> <BEA-000126> <All session objects should be serializable to replicate. Check the objects in your session. Failed to replicate non-serializable object.
    java.rmi.MarshalException: failed to marshal update(Lweblogic.cluster.replication.ROID;ILjava.io.Serializable;Ljava.lang.Object;); nested exception is:
    java.io.NotSerializableException: com.thortech.xl.webclient.workflowutil.ImageGenerator$Field
    at weblogic.rjvm.BasicOutboundRequest.marshalArgs(BasicOutboundRequest.java:92)
    at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:221)
    at weblogic.cluster.replication.ReplicationManager_1035_WLStub.update(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    Truncated. see log file for complete stacktrace
    Caused By: java.io.NotSerializableException: com.thortech.xl.webclient.workflowutil.ImageGenerator$Field
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
    at java.util.HashMap.writeObject(HashMap.java:1195)
    at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    Truncated. see log file for complete stacktrace
    >
    <Feb 7, 2012 10:56:48 AM PST> <Error> <Cluster> <BEA-000126> <All session objects should be serializable to replicate. Check the objects in your session. Failed to replicate non-serializable object.
    java.rmi.MarshalException: failed to marshal update(Lweblogic.cluster.replication.ROID;ILjava.io.Serializable;Ljava.lang.Object;); nested exception is:
    java.io.NotSerializableException: com.thortech.xl.webclient.workflowutil.ImageGenerator$Field
    at weblogic.rjvm.BasicOutboundRequest.marshalArgs(BasicOutboundRequest.java:92)
    at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:221)
    at weblogic.cluster.replication.ReplicationManager_1035_WLStub.update(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    Truncated. see log file for complete stacktrace
    Caused By: java.io.NotSerializableException: com.thortech.xl.webclient.workflowutil.ImageGenerator$Field
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
    at java.util.HashMap.writeObject(HashMap.java:1195)
    at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    Truncated. see log file for complete stacktrace
    >
    ERROR,07 Feb 2012 10:56:51,516,[org.apache.struts.actions.DispatchAction],Request[resourceWorkflows] does not contain handler parameter named method
    =============================
    Anyone encountered this before in the clustered setup ?
    Thanks,

    Hello,
    But if you see the trace, it is coming from the OOTB library. Isn't it ? It doesn't indicate if there is any issue in any custom beans.
    java.io.NotSerializableException: com.thortech.xl.webclient.workflowutil.ImageGenerator$FieldMoreover, i see this error in the log with case 2: ("configure" data flow). However, it is working and the the UI is showing me the data flow with this error in the log.
    My major concern is case 1: ("edit" workflow) which is not showing me anything on the UI ?
    Ideally, it should trigger Nexaweb client to populate the workflows in the UI.
    *1 interesting observation:*
    If i go to "Design console" -> process definition -> "Render workflow",
    then it opens the workflow in the default explorer and the url which is opened in the browser is same as the previous case. It is working here as expected. Does this means the problem is with Nexaweb client load in the UI in case 1. How to fix this ?
    Please suggest.
    Thanks,
    Edited by: oimuser007 on Feb 7, 2012 2:44 PM

Maybe you are looking for

  • Get all users in Portal

    Hi all, I'd like to ask you for help with my Portal application. I need to retrieve all users in Portal. Now I'm using searchUsers method of UserFactory object. It returns to me all users, but it is very time-consuming operation for cca. 3500 users i

  • Open an old mail account from a new mac

    My late lamented MacBook Pro suffered Death By Coffee. Fortunately the primary HD was undamaged, so I had a tech put it in a USB enclosure and now I can boot up "my computer" from any mac later than something like 2009. This has however become tediou

  • Looking for a music video app.

    I'm looking for an app that will let me record one long video (where I'm miming to an entire song in time) then allow me to replace parts of it with other short videos and stills, not changing the timing of the long video. Does iMovie have this facil

  • HT4191 I have a note that I started in my Notes app. For some reason, its no longer showing up on my iPod.

    but is still showing up on the email it is attached to, the other notes attached to this email are not having this problem. What to do?

  • When converting pdf to tif, I sometimes get black boxes rather than text.

    This occurs with pdfs which are rendered one 'layer' at a time upon opening or panning, although I don't beleive they are layered.  No layers display in the navigation pane.  I don't know the original file format, could be dwg.  Do you know how to co