On Sat, Nov 19, 2011 at 4:52 PM, jlazeraski <supreme_java_gur...@yahoo.com> wrote: > The big one for me is the server side statefulness. Maybe I misunderstood > this, but I am really worried about the ability for Wicket to scale given > that it keeps per user object trees in memory for the page the user is on.
the question is: do you *really* need to scale? :) so far you know that Wicket keeps *some* state in session. have you measured how much it actually is on average per user? have you calculated how many user session fit into your server's ram given average user session size. the big question then is what will bottle neck first, your ram, your cpu, or your network backplane for the cluster? just because something is stateful doesnt mean it automatically does not scale. in my current place we use two beefy servers to run the wicket portion of the app that manages an relatively large university. thats right, two servers - each running two instances of tomcat. will your app have more load then that? it is of course much easier to counter this: if i write my app completely stateless then i wont even have this porblem. of course, you are right. the qustions then become: will you be able to keep your app completely stateless? if your ui is complex, probably not. another question is: how much money will you save by using something like Wicket which allows you a much faster coding page and a much more maintenable code base? Will this savings be enough to buy more servers? more ram for the servers? a fiber backplane for the cluster? see what im getting at? -igor > On the one hand, that is pretty nifty especially for the swing like event > driven approach with ajax, but where I am not sure of is with the memory > consumption used continuously on a server, it seems to me you would reduce > the number of users per server you could handle. More so, replication of > state information would require 2 (or more) servers in a cluster to have the > same sort of object tree + state in memory to have any sort of fault > tolerance. Am I correct in understanding how Wicket maintains an object tree > per user on the server side? If this is the correct understanding then to me > the stateless model of using a REST api or Struts actions where each request > comes in with a session id, and minimal data is in the session.. typically > just a userId tied to the sesion id so data can then be looked up using the > userId. Again, if I am correct, then the struts/mvc approach typically is > keep as little in memory across requests, but each request may need to spend > some processing time loading up data to reconstruct a page to send back as a > response (or set as attributes for a JSP page to use to render the response > with). So there is a bit more processing and temporary memory use, but the > memory expands/contracts continuously as users make requests and responses > go back. At least as far as I understand the whole scalability side of > things, this is better for more user capacity. As for session replication, > at least in the old days, you had to replicate session data to at least one > other server in the cluster. In Wicket, how is this done? > > Another area I am not keen with at all with wicket which is mentioned is > having to build the object tree code the same way the html page is. With > element Ids, I am a little confused as to why we cant simply insert the > component using the element id and let wicket figure out where to stick it > on the page. To me, as it scans the html page for wicket ids, it should be > able to pluck wicket component/objects from a Map using the same ID and put > it where it needs to be. This is one of the areas I have had some trouble > getting right. If Wicket did not have this requirement, you could rearrange > panels, components, etc on a page and not have to worry about any server > side code change, redeploy, etc. It would, in my opinion "fix" Wicket as the > ultimate framework (barring my question about scalability/session memory > above also being resolved). Someone mentioned Wicket 6 will resolve > something of this.. if you could elaborate (or point a link) that would be > great. I would love to see them resolve this issue in the framework. It > would be great to allow a web page designer build up the page, then I add > dynamic elements, then they decide to change things around and simply edit > the page and redeploy and see the changes, then do it again until they like > it. > > Lastly, the bookmarkable and ugly link stuff.. I also agree that it's a bit > of a pain. It may make sense to some, but having to worry about bookmarkable > links and when to use them or not, etc adds to the complexity and learning > curve. I think this is one other area I enjoy about Struts, but perhaps I've > not worked enough with Wicket to fully realize why its needed and/or can't > just be avoided. > > Otherwise, I love the idea of Wicket. I've often thought of making my own > template framework like how I describe above.. stateless on the server side > (no object model in memory), modular components that can be reused on any > page, without all the JSP scriplet nightmares. > > Look forward to any replies. Thanks all. > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4087666.html > Sent from the Users forum mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
