XRebel is on the todo list but it's good to able to log it in production. Thanks alot Romain and Mark for the information!
On 9 February 2015 at 11:26, Mark Struberg <[email protected]> wrote: > Often both numbers are interesting. > > > The complete session size is important to know as it tells you how much > memory you need (before having to swap sessions to disc). And often devs > put way too much stuff into the session without noticing. > > The delta-size is important for the network traffic on 'real' clustering. > But be aware that there is no specified way to know what parts of the > session account for a delta. In Tomcat an attribute gets delta-replicated > ONLY if the attribute gets set. > > > E.g. if you have a Map<String, String> vals; and set this into the session > once and then just change the content, then this attribute will NOT get > delta-replicated by Tomcat! (Despite it's content did change). You will > need an explicit set on that attribute. > > But be aware that this might trigger another dead spot in the servlets > spec. Tomcat does detect that you set the same attribute instance again and > will NOT fire a attribute destroyed event. So Tomcat _actively_ suppresses > the destroy event in that very case. But other containers do not. They will > simply destroy your 'old' attribute value (which is actually the same as > the 'new' one) and your application might blow up. > > Long story short: if you activate delta-replication then you leave the > portable route and you need to know excactly what YOUR container does in > that case. > > LieGrue, > strub > > > > > > > On Wednesday, 4 February 2015, 20:38, Romain Manni-Bucau < > [email protected]> wrote: > > > after all this effort you'll maybe be disappointed. For clustering (in > > particular tomcat one) what is important is not session size but delta > > size and throughoutput. typically if your session does 10M but only > > 200b are moving between nodes once a user is conencted for instance > > this is fine. About 1.5K then it depends as usual of your contraints > > and infra. Best way to know is to measure performances and "cost" > > (cloud network is not always free for instance). Once you have it you > > can compare it to what you would like / what you can accept. There is > > no general rule sadly > > > > > > Romain Manni-Bucau > > @rmannibucau > > http://www.tomitribe.com > > http://rmannibucau.wordpress.com > > https://github.com/rmannibucau > > > > > > 2015-02-04 20:31 GMT+01:00 Karl Kildén <[email protected]>: > >> OK so I did > >> > >> grant codeBase "file:${catalina.home}/webapps/myapp/-" > > { > >> permission java.security.AllPermission; > >> > >> }; > >> > >> > >> https://gist.github.com/karlkilden/51233a012071a8f82c26 > >> > >> It works... Thanks - I was not very comfortable editing the security > policy > >> then again we do hosting and one app per TomEE so it hardly matters > anyway. > >> > >> My session size seems to be 1.5KB I wonder if that's to large for a > >> clustering setup? I think I will use the JDBC storage one for > clustering > >> and use sticky sessions > >> > >> cheers > >> > >> On 4 February 2015 at 20:01, Romain Manni-Bucau > > <[email protected]> > >> wrote: > >> > >>> sure > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-02-04 19:59 GMT+01:00 <[email protected]>: > >>> > Tried it, tomcat kills the thread and logs a security something > >>> exception. Guess i would need to turn off security manager > >>> > > >>> > Skickat från min iPhone > >>> > > >>> >> 4 feb 2015 kl. 19:52 skrev Romain Manni-Bucau > > <[email protected]>: > >>> >> > >>> >> @Karl: if you didnt wrap it just use session fielf of the > > session you > >>> >> get (by reflection). Should be serializable > >>> >> > >>> >> > >>> >> Romain Manni-Bucau > >>> >> @rmannibucau > >>> >> http://www.tomitribe.com > >>> >> http://rmannibucau.wordpress.com > >>> >> https://github.com/rmannibucau > >>> >> > >>> >> > >>> >> 2015-02-04 19:49 GMT+01:00 <[email protected]>: > >>> >>> Hello Mark, httpsession does not implement Serializable > > and tomcat > >>> sessionholder does not. The actual session is not obtainable :( > >>> >>> > >>> >>> Skickat från min iPhone > >>> >>> > >>> >>>> 4 feb 2015 kl. 16:52 skrev Mark Struberg > > <[email protected]>: > >>> >>>> > >>> >>>> did that via a SerlvetFilter and just serialized the > > session into a > >>> byte[] and output the size. As benefit you also see early on whether > > you > >>> have something which is not properly Serializable and would fail on a > >>> cluster. > >>> >>>> > >>> >>>> LieGrue, > >>> >>>> strub > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>>>> On Monday, 2 February 2015, 20:01, Karl Kildén > > < > >>> [email protected]> wrote: > >>> >>>>>> Hello! > >>> >>>>> > >>> >>>>> Anyone got some ideas on how to measure session > > size? > >>> >>>>> > >>> >>>>> I serialized the JSF sessionmap and it gave some > > hints but seems not > >>> >>>>> everything is there. If I CDI scope with Session > > and put a lot of > >>> stuff in > >>> >>>>> my bean the JSF map does not grow and I can't > > figure out how to > >>> serialize > >>> >>>>> the session manually... > >>> >>>>> > >>> >>>>> If anyone knows exactly how viewstate and > > sessionstate is stored for > >>> a > >>> >>>>> modern CDI/JSF application I would be glad to hear > > about some > >>> internals. > >>> >>>>> > >>> >>>>> I have no issues - just want to know this so I can > > keep tabs as my > >>> app grows > >>> >>>>> > >>> >>>>> cheers > >>> >>>>> > >>> > > >
