Ok, so i should create an issue in JIRA for this right ?
If so, i'll create the issue right away but it would be great if someone
could take a look at it quickly as this is affecting an already in
production application. I know no one is getting paid to do so, but can u
see it like a community friend favour ? :o)
On 7/2/07, James Carman <[EMAIL PROTECTED]> wrote:
I think we may need to look into this a bit, because the service
serialization stuff seems to be flawed (at least from my perusal of
the code).
On 7/2/07, HugoPalma <[EMAIL PROTECTED]> wrote:
>
> I really would appreciate more info on this. This is completely messing
up
> the application behaviour in a clustered env. This seems to be cause of
> weblogic not being able to replicate session as every time it tries to
> replicate this exception gets thrown.
>
> Please, any workarounds, ideas ?
>
> Thanks.
>
>
> James Carman wrote:
> >
> > It's a thread local variable. So, it's only set for the calling
thread
> > (the
> > webapp's startup thread). I think the thread local is what's messing
it
> > up.
> >
> > On 5/18/07, Hugo Palma <[EMAIL PROTECTED]> wrote:
> >>
> >> But the setServiceSerializationSupport method is called from the
startup
> >> method of RegistryInfrastructureImpl. So, it should be initialized as
> >> soon
> >> as the Tapestry servlet creates the registry right ?
> >>
> >> Actually, i just realized i have load-on-startup=0 in the tapestry
> >> servlet. This could be the thing that keeps the
> >> ServiceSerializationSupport
> >> from getting set in the other cluster node. Or not ?
> >>
> >> On 5/18/07, James Carman <[EMAIL PROTECTED]> wrote:
> >> >
> >> > Here's the code:
> >> >
> >> > private static final ThreadLocal _threadLocal = new
ThreadLocal();
> >> >
> >> > /**
> >> > * Returns the previously stored SSS.
> >> > *
> >> > * @throws ApplicationRuntimeException
> >> >
> >> >
> >> > * if no SSS has been stored.
> >> > */
> >> > public static ServiceSerializationSupport
> >> getServiceSerializationSupport()
> >> > {
> >> > ServiceSerializationSupport result = null;
> >> >
> >> > WeakReference reference = (WeakReference)
_threadLocal.get();
> >> >
> >> >
> >> > if (reference != null)
> >> > result = (ServiceSerializationSupport) reference.get();
> >> >
> >> > if (result == null)
> >> > throw new
> >> ApplicationRuntimeException(SerMessages.noSupportSet
> >> > ());
> >> >
> >> >
> >> > return result;
> >> > }
> >> >
> >> > /**
> >> > * Stores the SSS instance for later access; if an existing SSS
is
> >> already stored, then an error
> >> > * is logged (should be just one SSS per class loader).
> >> >
> >> >
> >> > */
> >> >
> >> > public static void setServiceSerializationSupport(
> >> > ServiceSerializationSupport
serviceSerializationSupport)
> >> > {
> >> > WeakReference reference = new
> >> WeakReference(serviceSerializationSupport);
> >> >
> >> >
> >> >
> >> > _threadLocal.set(reference);
> >> >
> >> > }
> >> >
> >> >
> >> > It's not initialized because it probably hasn't serialized anything
yet
> >> > for that specific thread on the other server. That's the scenario
I am
> >> > imagining after looking at that code. Come to think of it, this
could
> >> > actually happen on the same server if serialization hasn't occurred
for
> >> that
> >> > request thread. So, server affinity may not solve all your
problems.
> >> I
> >> > didn't write this particular piece of code, so I hope I am reading
it
> >> > correctly (I think I am).
> >> >
> >> > On 5/18/07, Hugo Palma < [EMAIL PROTECTED]> wrote:
> >> > >
> >> > > I think we'll be able to use server affinity, still this
shouldn't be
> >> > > required.
> >> > > I still don't understand why is ServiceSerializationSupport not
> >> > > getting initialized in one of the cluster nodes.
> >> > >
> >> > > That's right, Tapestry is handling all the serialization stuff.
> >> > >
> >> > > On 5/18/07, James Carman < [EMAIL PROTECTED]> wrote:
> >> > > >
> >> > > > Can you use server affinity for your application? Basically,
> >> > > > HiveMind looks for a thread local variable to be set to
deserialize
> >> your
> >> > > > service proxies. The variable gets set on the initial server
where
> >> the
> >> > > > session is serialized first, but it's not set on the other
server
> >> where it's
> >> > > > deserialized. I'm assuming Tapestry is doing this behind the
> >> scenes for you
> >> > > > and you have no control over what gets serialized?
> >> > > >
> >> > > > On 5/18/07, Hugo Palma < [EMAIL PROTECTED]> wrote:
> >> > > > >
> >> > > > > I'm getting the following exception all over the logs in a
> >> > > > > clustered environment :
> >> > > > >
> >> > > > > org.apache.hivemind.ApplicationRuntimeException: The
> >> > > > > ServiceSerializationSupport instance has not been set; this
> >> indicates that
> >> > > > > the HiveMind Registry has not been created within this JVM.
> >> > > > >
> >> > > > > The application seems to work ok, but we are also having some
> >> > > > > session replication problems with the same application that
might
> >> be related
> >> > > > > to this issue also.
> >> > > > > Any ideas about might be causing this would be great. I'm
using
> >> > > > > hivemind-1.1.1.
> >> > > > >
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
> --
> View this message in context:
http://www.nabble.com/Registry-trouble-in-a-cluster-tf3779171.html#a11395264
> Sent from the Hivemind - User mailing list archive at Nabble.com.
>
>
