Re: Evaluation of Cocoon

[Eric Jain <Er...@isb-sib.ch>]

>> Subsequent requests may be routed to different servers.
>> Here I see a possible problem with Cocoon

> The same problem will apply to any site that uses sessions.

Yes, though most application servers have some mechanism for replicating
sessions. Having 'sticky' sessions is certainly a good idea for
performance reasons, but if one machine goes down in such a setup no one
is affected.

Anyways, in our case the servers are located at different sites, and the
application is completely stateless.


> you can use flow and JXTemplate if you don't use sendPageAndWait(),
> only using sendPage(), thus you're not using continuations, and are
> therefore stateless.

Thanks, I hadn't realized that I could use flow without the
continuations feature. If this is so, there shouldn't be any problem.


--
Eric Jain


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

RE: Evaluation of Cocoon

[Slappy Tang <sl...@bjohnson.net>]

> >> Subsequent requests may be routed to different servers.
> >> Here I see a possible problem with Cocoon
> 
> > The same problem will apply to any site that uses sessions.
> 
> Yes, though most application servers have some mechanism for 
> replicating sessions. Having 'sticky' sessions is certainly a 
> good idea for performance reasons, but if one machine goes 
> down in such a setup no one is affected.

Umm.. someone can correct me if I'm wrong.  But I believe
things like sticky sessions and session replication have
nothing to do with Cocoon.  This all depends on the servlet
container you're using to serve up cocoon correct?

Also - at least from my experience with the terminology
"sticky" sessions.. this usually has to do with a load
balancer and sending requests to one particular machine.
I.e. user1 connects to the website on server2 and gets
a session.. from then on that session's requests are all
processed by the same server (server2) until the session
expires.

So - I may be wrong, but I think most of these requirements
that you have are probably not dependent on Cocoon itself
but your infrastructure and servlet container.

> Anyways, in our case the servers are located at different 
> sites, and the application is completely stateless.

Well.. I dont think this should affect Cocoon anymore than
any other Servlet/JSP web development.

- Brent



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

RE: Evaluation of Cocoon

[Brent L Johnson <br...@bjohnson.net>]

> >> Subsequent requests may be routed to different servers.
> >> Here I see a possible problem with Cocoon
> 
> > The same problem will apply to any site that uses sessions.
> 
> Yes, though most application servers have some mechanism for 
> replicating sessions. Having 'sticky' sessions is certainly a 
> good idea for performance reasons, but if one machine goes 
> down in such a setup no one is affected.

Umm.. someone can correct me if I'm wrong.  But I believe
things like sticky sessions and session replication have
nothing to do with Cocoon.  This all depends on the servlet
container you're using to serve up cocoon correct?

Also - at least from my experience with the terminology
"sticky" sessions.. this usually has to do with a load
balancer and sending requests to one particular machine.
I.e. user1 connects to the website on server2 and gets
a session.. from then on that session's requests are all
processed by the same server (server2) until the session
expires.

So - I may be wrong, but I think most of these requirements
that you have are probably not dependent on Cocoon itself
but your infrastructure and servlet container.

> Anyways, in our case the servers are located at different 
> sites, and the application is completely stateless.

Well.. I dont think this should affect Cocoon anymore than
any other Servlet/JSP web development.

- Brent



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org