Registry trouble in a cluster

[HugoPalma]

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.

[jwcarman]

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 <hugo.m.palma@...> 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.

[HugoPalma]

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 <james@...> 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 <hugo.m.palma@...> 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.

[jwcarman]

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 <hugo.m.palma@...> 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 <james@...> 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 <hugo.m.palma@...> 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.

[HugoPalma]

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 <james@...> 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 <hugo.m.palma@...> 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 <james@...> 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 <hugo.m.palma@...> 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.

[jwcarman]

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 <hugo.m.palma@...> 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 <james@...> 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 <hugo.m.palma@...> 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 <james@...> 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 <hugo.m.palma@...> 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.

[HugoPalma]

I see your point.
So do you see any way around this besides using server affinity ?

On 5/18/07, James Carman <james@...> 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 <hugo.m.palma@...> 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 <james@...> 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 <hugo.m.palma@...> 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 <james@...> 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 <hugo.m.palma@...> 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.

[HugoPalma]

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 <[e-mail]> 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 <[e-mail]> 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 < [e-mail]> 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 < [e-mail]> 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 < [e-mail]> 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.
> > > > >
> > > >
> > > >
> > >
> >
>

[jwcarman]

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 <hugo.m.palma@...> 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 <hugo.m.palma@...> 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 <james@...> 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 < hugo.m.palma@...> 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 < james@...> 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 < hugo.m.palma@...> 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.
>
>

[HugoPalma]

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 <james@...> 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 <hugo.m.palma@...> 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 <hugo.m.palma@...> 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 <james@...> 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 < hugo.m.palma@...> 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 < james@...> 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 < hugo.m.palma@...> 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.
>
>