You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by John Jimmy Dondapati <dj...@gmail.com> on 2008/10/07 23:23:05 UTC
Scalability of T5 : Form Wizard options
Hi,
We are evaluating Tapestry for a couple of months and are very
interested in using it in a huge project that will have a minimum of 30k
users when it goes up. Since T5 is not yet production ready we are seeking
for advice to know how scalable Tapestry forms can be.
We need a multipage form wizard that populates part of a requestObject in
each page and finally persists it to a database. The user should be able to
fill the form in parts whenever he feels like - page 1,2 today and page 3,4
next week or something like that.
Here are the options with T5 (from what we could dig up) :
1. have a gaint ASO Request object for each user, but that is not at all
scalable.
2. Pass on the Request object between the Pages using
Page1.java
Object onSubmitFromForm()
{
nextPage.setRequestObject(this.requestObject());
return nextPage;
}
Page2.java
object onPassivate(Object RequestObject)
{
return RequestObject
}
void onActivate(Object requestObject)
{
this.requestObject = requestObject;
}
It looks like I cannot pass my custom Classes (requestObjects) this way.
Are only the built-in datatype classes allowed for OnActivate() and
OnPassivate() e.g. String or Long ?
3. Persist each part of the form in each page (database or some ASO
like Map(id, requestObject) ) and pass on the id. That way we can retrieve
the previously entered values onPrev() and onSubmit()
4. @Persist all the form feilds between requests?
We dont know if any of these would work for us coz we are looking at min 10k
concurrent users for this form wizard when it goes up. Are we missing some
other approach. Please advise. Thanks!
--
Cheers,
John
Re: Scalability of T5 : Form Wizard options
Posted by John Jimmy Dondapati <dj...@gmail.com>.
Hi Renat,
First thanks for the detailed discussion.
On Wed, Oct 8, 2008 at 2:16 AM, Renat Zubairov <re...@gmail.com>wrote:
> Hello John,
>
>
> >>
> >> In this case, you wouldn't use the page activation context, as you're
> >> filling the page properties yourself. As Tapestry uses
> redirect-after-post
> >> by default (and not using it can lead to several problems), you would
> need
> >> to @Persist("flash") the property in all pages. The single giant ASO
> would
> >> be a better fit instead of this.
> >>
> >
> > thanks for correction. But the single giant ASO would not be scalable
> for
> > us as there will tens of thousands of concurrent users.
> >
>
> You can off course disable redirect-after-post and track resubmissions
> with different mechanism. In theory one could generally think about
> storing data on the client side, i.e. in the hidden form fields or in
> the URL. Please note that when discussing the solution we are
> generally speaking of limitations/features of the Web applications in
> general, you would have the same issues wherever web application you
> would have, i.e. T5, Spring Web Flow, JSW, Ruby on Rails of PHP.
> Stateless nature of HTTP communication is the reason, not the
> technology in use.
>
I understand where you are coming from. Stalelessness of the HTTP is a best
& worst thing for the web developement depending on the application you are
developing. But I hear there is some kind of work around for it with Spring
Web flow & JSF. I am exploring that to understand more on how they deal with
this issue. I am also wondering if this is a feature that Spring Web Flow
offers then why not integrate it with Tapestry?
>
> IMHO heavy session state is generally not good, due to the overhead of
> session state replication in the cluster nodes, however some load
> balancing techniques (e.g. sticky sessions) could be a acceptable
> solution.
>
> In case user state is not stored in the session then it should be
> stored somewhere else - e.g. on the user side. It means that you could
> either encode the state in the URL (and keep in mind the limitations
> of the URL length). Other possibility is hidden form and POST. You can
> use/extend the Form tag to encapsulate additional fields that will
> store the user state (I'm quite sure this functionality is already
> exists in T5).
>
> So basically it's only a question where to store user state - on
> server (HTTP Session) or on client (and transfer it with every
> GET/POST request). Server solution is considered to be not scalable
> enough. However client solution is also not free from problems. For
> example let's imagine we have 500 kb of the user state. In case we
> will store in on client it will be attached to every client request,
> so request size will really increase. What will also be increased is
> the request processing time because any data sent from the client can
> not be trusted, therefore apart from network latency and
> deserialization time we need to consider validation/decryption
> overhead. The server-side solution will generally work faster due to
> the fact that most of the clusters have gigabit ethernet between nodes
> :) and server-side data is protected. Some solutions like sticky
> sessions will minimize the whatsoever overhead we will have.
>
In theory the Client side storage is an interesting option from
technological point of view. But it is an option that we are not allowed to
have coz of the same concerns you have already stated. The security of the
data, overhead and the request size are also of huge concern to us.
I am sure we are the first ones to face a challenge like this and there must
be some kind of workaround to manage the state without overkilling the
servers when the users scale.
>
> Another good question is what is stored in the session. And here we
> come to the point where development framework makes huge difference.
> Tapestry have "Static structure - dynamic behavior" principle which
> leads to some limitations (e.g. can't create components runtime),
> however it's a huge advantage which heavily limit the HTTP Session
> usage. With T5 one can write a stateless applications - i.e. HTTP
> session is not used at all. Try it with JSF :)
>
>
> P,S, Sorry for the long post.
We are glad you gave us the whole big picture. Thanks for the insights
mate.
>
> --
> Best regards,
> Renat Zubairov
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Cheers,
John
Re: Scalability of T5 : Form Wizard options
Posted by Renat Zubairov <re...@gmail.com>.
Hello John,
>>
>> In this case, you wouldn't use the page activation context, as you're
>> filling the page properties yourself. As Tapestry uses redirect-after-post
>> by default (and not using it can lead to several problems), you would need
>> to @Persist("flash") the property in all pages. The single giant ASO would
>> be a better fit instead of this.
>>
>
> thanks for correction. But the single giant ASO would not be scalable for
> us as there will tens of thousands of concurrent users.
>
You can off course disable redirect-after-post and track resubmissions
with different mechanism. In theory one could generally think about
storing data on the client side, i.e. in the hidden form fields or in
the URL. Please note that when discussing the solution we are
generally speaking of limitations/features of the Web applications in
general, you would have the same issues wherever web application you
would have, i.e. T5, Spring Web Flow, JSW, Ruby on Rails of PHP.
Stateless nature of HTTP communication is the reason, not the
technology in use.
IMHO heavy session state is generally not good, due to the overhead of
session state replication in the cluster nodes, however some load
balancing techniques (e.g. sticky sessions) could be a acceptable
solution.
In case user state is not stored in the session then it should be
stored somewhere else - e.g. on the user side. It means that you could
either encode the state in the URL (and keep in mind the limitations
of the URL length). Other possibility is hidden form and POST. You can
use/extend the Form tag to encapsulate additional fields that will
store the user state (I'm quite sure this functionality is already
exists in T5).
So basically it's only a question where to store user state - on
server (HTTP Session) or on client (and transfer it with every
GET/POST request). Server solution is considered to be not scalable
enough. However client solution is also not free from problems. For
example let's imagine we have 500 kb of the user state. In case we
will store in on client it will be attached to every client request,
so request size will really increase. What will also be increased is
the request processing time because any data sent from the client can
not be trusted, therefore apart from network latency and
deserialization time we need to consider validation/decryption
overhead. The server-side solution will generally work faster due to
the fact that most of the clusters have gigabit ethernet between nodes
:) and server-side data is protected. Some solutions like sticky
sessions will minimize the whatsoever overhead we will have.
Another good question is what is stored in the session. And here we
come to the point where development framework makes huge difference.
Tapestry have "Static structure - dynamic behavior" principle which
leads to some limitations (e.g. can't create components runtime),
however it's a huge advantage which heavily limit the HTTP Session
usage. With T5 one can write a stateless applications - i.e. HTTP
session is not used at all. Try it with JSF :)
P,S, Sorry for the long post.
--
Best regards,
Renat Zubairov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Scalability of T5 : Form Wizard options
Posted by John Jimmy Dondapati <dj...@gmail.com>.
On Tue, Oct 7, 2008 at 7:11 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Tue, 07 Oct 2008 18:23:05 -0300, John Jimmy Dondapati <
> djohnjimmy@gmail.com> escreveu:
>
> Here are the options with T5 (from what we could dig up) :
>> 2. Pass on the Request object between the Pages using
>>
>> Page1.java
>> Object onSubmitFromForm()
>> {
>> nextPage.setRequestObject(this.requestObject());
>> return nextPage;
>> }
>>
>
> In this case, you wouldn't use the page activation context, as you're
> filling the page properties yourself. As Tapestry uses redirect-after-post
> by default (and not using it can lead to several problems), you would need
> to @Persist("flash") the property in all pages. The single giant ASO would
> be a better fit instead of this.
>
thanks for correction. But the single giant ASO would not be scalable for
us as there will tens of thousands of concurrent users.
>
>
> It looks like I cannot pass my custom Classes (requestObjects) this way.
>> Are only the built-in datatype classes allowed for OnActivate() and
>> OnPassivate() e.g. String or Long ?
>>
>
> You can use String[] and List as well.
>
Cool. didnt know that.
>
>
> We dont know if any of these would work for us coz we are looking at min
>> 10k concurrent users for this form wizard when it goes up. Are we missing
>> some other approach. Please advise. Thanks!
>>
>
> Could you use the middle ground solution of storing a temporary object in a
> database at each page, reloading it at each page and only storing the object
> in the right table in the end of the wizard? You trade database
> communication and processing for per-user memory consumption.
>
We thought about this too. But we have messaging (Webspher MQ) in the middle
and accessing the data zone for every page is gonna be really messy. I
guess, we cant have it all our way.
>
> In any case, huge forms are always a pain and I try to avoid them as much
> as I can.
>
Yes, its a real big pain. But I hear that JSF with SWF ( Spring Web Flow )
addresses all these concerns somehow. I wish Tapestry would also come up
with some components to make the wizard flow easier. This is the only major
concern for us in deciding whether or not to use tapestry in the production.
I guess we will have to wait for a while.
Any ideas on how Tapestry is compared to SWF (in regard to managing the
state)?
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> Consultor, desenvolvedor e instrutor em Java
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Cheers,
John
Re: Scalability of T5 : Form Wizard options
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 07 Oct 2008 18:23:05 -0300, John Jimmy Dondapati
<dj...@gmail.com> escreveu:
> Here are the options with T5 (from what we could dig up) :
> 2. Pass on the Request object between the Pages using
>
> Page1.java
> Object onSubmitFromForm()
> {
> nextPage.setRequestObject(this.requestObject());
> return nextPage;
> }
In this case, you wouldn't use the page activation context, as you're
filling the page properties yourself. As Tapestry uses redirect-after-post
by default (and not using it can lead to several problems), you would need
to @Persist("flash") the property in all pages. The single giant ASO would
be a better fit instead of this.
> It looks like I cannot pass my custom Classes (requestObjects) this way.
> Are only the built-in datatype classes allowed for OnActivate() and
> OnPassivate() e.g. String or Long ?
You can use String[] and List as well.
> We dont know if any of these would work for us coz we are looking at min
> 10k concurrent users for this form wizard when it goes up. Are we
> missing some other approach. Please advise. Thanks!
Could you use the middle ground solution of storing a temporary object in
a database at each page, reloading it at each page and only storing the
object in the right table in the end of the wizard? You trade database
communication and processing for per-user memory consumption.
In any case, huge forms are always a pain and I try to avoid them as much
as I can.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
Consultor, desenvolvedor e instrutor em Java
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org