Hello Simone, talking about continuations, did you already find a solid way to handle high traffic sites with many concurrent continuations and memory useage? It bothers me a little that when building sites, we have to keep track of the number of continuations (we had a large site with many visitors and a poll on the homepage having a continuation. This brought the site down a few times).
You mentioned serializing continuations to diskStore (ofcourse, the flowscript/javaflow writer should make sure al things in the cont are serializable then). Is this feasible? The other day I also thought about the cocoon caches having this StoreJanitor trying to free memory from it when JVM is low on memory. It just does not make sense to me, that this is only tried regarding the cache, while currently, also continuations might be the reason for a low on memory JVM. Suppose, I have a healthy cache, nicely populated, and a high cachehit range, but it happened to be that many many continuations have been created, all long lived (5 hours), and all quite large (1 continuation can be very large in memory). Now, due to this continuations, JMV is low on memory, implying the StoreJanitor to run, removing my cache, and certainly not solving any problem. So I was wondering if you had some new ideas on this subject...though, perhaps the dev-list is more appropriate for it. WDYT? Regards Ard > > Hi Toby, > I think you are right. What a continuation does (should do) > is dump the > local variables and restore them before restarting the flow. > This means > that if you write var a = 1; then create a continuation, when > you return > to that continuation a should be 1 again, even if in other > continuations > it has been changed to 2,3 or 4. > > There is surely one known limitation to this : if you say var > bean = new > MyBean(); bean.setX(1); then produce a continuation, then after the > continuation you call bean.setX(2), even if you go back to > the previous > continuation you will find that bean.getX() == 2, because the LOCAL > VARIABLE is still your bean, but it's internal state is not manageable > by the continuation (more formally, your local variable is a > pointer to > a bean, which is correctly restored when you go back to the > continuation, but the data it points to is not serialized/deserialized > by the continuation). > > But this is not your case, in this case you are setting a simple > javascript variable, so it should work as you say, at least AFAIK :) > > Please, file a bug about it. > > Simone > > Toby wrote: > > >Jason Johnston wrote: > > > > > >>First you assign the 'useless' variable a String value, then you > >>create the continuation. When you resume the continuation the first > >>time, you re-assign the 'useless' variable so that it now holds an > >>Array value (String.split() returns an Array). When you resume the > >>continuation again, you try to call .split() on the 'useless' var, > >>which is now an Array, and the error is appropriately > thrown since an > >>Array has no such method. > >> > >> > > > >When I resume the continuation again, I'm resuming it from before > >assigning the array, so one would think that useless (which > is a local > >variable) would still contain a string! > > > >What am I missing? > > > > > >Toby > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Simone Gianni > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
