Cookie bug using Administrative Server as part of the Cluster

Question

All using Weblogic 6.0:
          Administrative Server running on Windows 2000 Professional
          Managed Server running on Windows 2000 Server
          Both machines running in the same cluster.
          Requests being proxied by the Windows 2000 Professional machine running IIS
          Ok, now that you know our test environment, here's a little about our bug.
          If we begin an http session with requests being fulfilled by the
          administrative server (through the proxy), and shut down and bring the
          managed server back up, everything is fine. (No big surprise.)
          However, if requests are being fulfilled by the managed server and the
          administrator goes down and then comes back up, we get a
          "ReplicationManager: object 722399223287670702 not found" error, where the
          number seems to refer to value stored in the cookie after the last OR
          symbol as shown below.
          When the session is created, the cookie contains the following value:
          session id =
          OnIXh5A6DxUWgBrA2qCLIDN0Co1dewmjdV1ze1isn9Wur2CHl2k2|60563422118895
          84610/-1062731365/7001/7002|4648941459387506517/-1062731381/7001/7002|722399
          223287670702
          When the administrative server goes down, the cookie contains the following
          value:
          session id =
          OnIXh5A6DxUWgBrA2qCLIDN0Co1dewmjdV1ze1isn9Wur2CHl2k2|60563422118895
          84610/-1062731365/7001/7002|NONE|722399223287670702
          When the administrative server comes back up, the cookie contains the
          following value:
          session id =
          OnIXh5A6DxUWgBrA2qCLIDN0Co1dewmjdV1ze1isn9Wur2CHl2k2|60563422118895
          84610/-1062731365/7001/7002|4563245475623454445/-1062731381/7001/7002|722399
          223287670702
          Its pretty obvious how the cookie id breaks down, information before the
          first OR is client info specific to each client, between the first and
          second OR is information regarding the first server from the cluster to
          fulfill the requests. The info between the second and third is the
          identification of the backup server containing the replicated version of the
          session. And the last bit of information seems to be an ID referring to the
          session object as stored in memory. As you can see, the value that the error
          is referring to never changes. SO WHY DOES THE OBJECT GET LOST?
          This is a big problem for us, as our resources are limited (as I assume
          everyone else's is). Is this just a bug? If so, is there a service pack
          already available? If its not a bug, it should be as resolving the bug
          allows the administrative server to be part of the cluster saving everyone
          the money for an extra machine and (here's the killer) the money for an
          extra weblogic license to run on a administrative server separate from the
          cluster (in which case it works fine, just costs a whole lot more).
          Well, I hope this is clear enough. If not please ask whatever you need to
          know. We are looking for any information anyone can provide.
          Thank you,
          Chad Griffith
          Software Engineer
          VisionTEK Inc.
          [email protected]
          

Answer 1

To answer your question, fail over works fine, i.e. if a session is
          maintained on the managed server, we can shut it down and the session is
          transferred to the administrative sever.
          The only problem we are having is when the session is on the MANAGED server,
          and the ADMIN server goes down and back up WITHOUT any session transfer.
          As for shutting down an admin server, you can bring it back up while managed
          servers are running by using the -Dweblogic.management.discover=TRUE
          setting.
          I hope this clarifies everything.
          Thanks again,
          Chad
          "Sioux France" <[email protected]> wrote in message
          news:[email protected]...
          > Is this an admin server problem though? Can you try the opposite? i.e. IS
          it
          > possible to connect to the Managed server for your http requests (through
          > the proxy)? If so, then shut down and bring back the managed server. I'd
          > expect that to go wrong in the same way? Likewise if you shutdown and
          bring
          > back the admin server in that configuration you would not have a problem?
          > "Chad Griffith" <[email protected]> wrote in message
          > news:[email protected]...
          > > All using Weblogic 6.0:
          > > Administrative Server running on Windows 2000 Professional
          > > Managed Server running on Windows 2000 Server
          > > Both machines running in the same cluster.
          > > Requests being proxied by the Windows 2000 Professional machine running
          > IIS
          > >
          > > Ok, now that you know our test environment, here's a little about our
          bug.
          > > If we begin an http session with requests being fulfilled by the
          > > administrative server (through the proxy), and shut down and bring the
          > > managed server back up, everything is fine. (No big surprise.)
          > >
          > > However, if requests are being fulfilled by the managed server and the
          > > administrator goes down and then comes back up, we get a
          > > "ReplicationManager: object 722399223287670702 not found" error, where
          the
          > > number seems to refer to value stored in the cookie after the last OR
          > > symbol as shown below.
          > >
          > > When the session is created, the cookie contains the following value:
          > > session id =
          > > OnIXh5A6DxUWgBrA2qCLIDN0Co1dewmjdV1ze1isn9Wur2CHl2k2|60563422118895
          > >
          >
          84610/-1062731365/7001/7002|4648941459387506517/-1062731381/7001/7002|722399
          > > 223287670702
          > >
          > > When the administrative server goes down, the cookie contains the
          > following
          > > value:
          > > session id =
          > > OnIXh5A6DxUWgBrA2qCLIDN0Co1dewmjdV1ze1isn9Wur2CHl2k2|60563422118895
          > > 84610/-1062731365/7001/7002|NONE|722399223287670702
          > >
          > > When the administrative server comes back up, the cookie contains the
          > > following value:
          > > session id =
          > > OnIXh5A6DxUWgBrA2qCLIDN0Co1dewmjdV1ze1isn9Wur2CHl2k2|60563422118895
          > >
          >
          84610/-1062731365/7001/7002|4563245475623454445/-1062731381/7001/7002|722399
          > > 223287670702
          > >
          > > Its pretty obvious how the cookie id breaks down, information before the
          > > first OR is client info specific to each client, between the first and
          > > second OR is information regarding the first server from the cluster to
          > > fulfill the requests. The info between the second and third is the
          > > identification of the backup server containing the replicated version of
          > the
          > > session. And the last bit of information seems to be an ID referring to
          > the
          > > session object as stored in memory. As you can see, the value that the
          > error
          > > is referring to never changes. SO WHY DOES THE OBJECT GET LOST?
          > >
          > > This is a big problem for us, as our resources are limited (as I assume
          > > everyone else's is). Is this just a bug? If so, is there a service pack
          > > already available? If its not a bug, it should be as resolving the bug
          > > allows the administrative server to be part of the cluster saving
          everyone
          > > the money for an extra machine and (here's the killer) the money for an
          > > extra weblogic license to run on a administrative server separate from
          the
          > > cluster (in which case it works fine, just costs a whole lot more).
          > >
          > > Well, I hope this is clear enough. If not please ask whatever you need
          to
          > > know. We are looking for any information anyone can provide.
          > >
          > > Thank you,
          > > Chad Griffith
          > > Software Engineer
          > > VisionTEK Inc.
          > > [email protected]
          > >
          > >
          >
          >