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