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.
