Continuations in clustered environments?

[Steve K <sh...@mm.st>]

Hey folks --

Is it possible for continuations to be used in a clustered environment? 
  A cursory look at ContinuationsManagerImpl leads me to believe that 
the continuation info is stored in forrest, a private HashSet. 
Therefore, it does not look like a cluster could share continuations -- 
is this right?

In order to make this possible, you would either have to share the 
continuation objects among the cluster, or serialize the continuation 
object itself on the web page.  The continuations could be shared in a 
database, or perhaps with a JavaGroups-enabled container, similar to how 
  Tomcat sessions are replicated.  Maybe SwarmCache can be used as-is 
for this?

It seems like it might be easier to serialize the continuation objects 
and pass them back to the server the same way the continuation IDs are 
passed around.  Of course they would have to be encrypted in some way to 
prevent people from tampering with them.  This may or may not be 
practical depending on how big these objects actually are.

Is anyone working on this, or am I totally wrong and it is already possible?

cheers,
-steve

Re: Continuations in clustered environments?

[Vadim Gritsenko <va...@verizon.net>]

Torsten Curdt wrote:

>
> > The continuations could be shared in a
>
>> database, or perhaps with a JavaGroups-enabled container, similar to 
>> how  Tomcat sessions are replicated.  Maybe SwarmCache can be used 
>> as-is for this?
>
>
> That's the spirit ;)


I wouldn't comment on feasibility of sharing continuations objects... 
But if something needs to be shared in the cluster environment, it is 
not a concern of Cocoon to implement this sharing. It is a concern of 
the application server which provides cluster environment to the 
servlets, Cocoon included.

Cocoon applications only need to store objects which supposed to be 
shared in one of the clustered services of the application server 
(example: JNDI, HTTP session). And IIRC continuations already can be 
stored in the HTTP session.


...

>> Is anyone working on this, or am I totally wrong and it is already 
>> possible?
>

See above -- even if possible there is nothing to work on.

Vadim

Re: Continuations in clustered environments?

[Torsten Curdt <tc...@vafer.org>]

> Is it possible for continuations to be used in a clustered environment? 
>  A cursory look at ContinuationsManagerImpl leads me to believe that the 
> continuation info is stored in forrest, a private HashSet. Therefore, it 
> does not look like a cluster could share continuations -- is this right?

If we keep the continuations in the session the usual
techniques might apply. Otherwise we'd need a different
kind of store.

> In order to make this possible, you would either have to share the 
> continuation objects among the cluster, or serialize the continuation 
> object itself on the web page.

 From a security POV I think this is not an option.
And the round-tripping makes no sense at all because continuations
happen on the server-side. This sounds like an ugly workaround for
a problem that should be solved somewhere else.
(Although it might seem appealing on the first glance)

 > The continuations could be shared in a
> database, or perhaps with a JavaGroups-enabled container, similar to how 
>  Tomcat sessions are replicated.  Maybe SwarmCache can be used as-is for 
> this?

That's the spirit ;)

> It seems like it might be easier to serialize the continuation objects 
> and pass them back to the server the same way the continuation IDs are 
> passed around.

Although I like the KISS approach in general I'd really prefer to keep
them on the server. Getting the continuation from a request is kinda
like you'd execute code that comes in from a request! -> BAAAAAD!!

> Of course they would have to be encrypted in some way to 
> prevent people from tampering with them.  This may or may not be 
> practical depending on how big these objects actually are.

Hm... this sounds more like a MS approach ;)

If we don't expose the continuation object
to the world there is no risk and no need
for encryption.

> Is anyone working on this, or am I totally wrong and it is already 
> possible?

...at least something we should discuss
--
Torsten