[8.0.1] Seaside loses continuation key handling 2 sessions

[klaus]

Hello,

scenario: Same application in two different browsers (Firefox 3.5.6, Internet Explorer 6.0) searches for a lot of customer data at the same time. Then an exception occurs in #WASession->#handleFiltered

Code: Select all

handleFiltered: aRequestContext
   | key continuation |
   key := aRequestContext request fields
      at: self actionField
      ifAbsent: [ ^ self start ].
   (key isString not and: [ key isSequenceable ])
      ifTrue: [ key := key first ].
      
   continuation := continuations
      at: key
      ifAbsent: [ ^ self unknownRequest ].
   continuation value

The value in the var #key will not be found in #continuations and #unknownRequest is called. What then will be happened is my problem. The problem ist, that obviously the session key is lost.

This does'nt happened when only one browser gets the data. The error is repeatable. Stack trace text is appended.

Kind Regards

Klaus

stack.txt

Stack trace

(22.7 KiB) Downloaded 49 times

[wembley]

Klaus -

Based on the information you provided, it isn't clear to me if "Same application in two different browsers (Firefox 3.5.6, Internet Explorer 6.0)" means to say that if multiple instances of either Firefox or IE (but not a mixture) are used, the problem does not occur.

[klaus]

Hello,

it doesn't matter whether you are using different browsers or the same.

Regards

Klaus

[jtuchel]

Klaus,

are you sure you're not messing with WASession or some other class override?
I don't see teh behaviour you describe. I am accessing my 8.0.1 based Seaside App from IE 8, Ff 3.5.7 in a Windows XP VM and from Safari on my Mac hosting the XP VM at the same time without any notable side effects.

cu

Joachim

[klaus]

Hi Joachim,

I subclassed #WASession with a own class, but didn't changed the behaviour instead of #unregister.
As I debugged #WASession -> #handleFiltered: I discovered, that when my two sessions are running the key in #handleFiltered: is a #OrderedCollection and runs in this piece of code:

Code: Select all

   (key isString not and: [ key isSequenceable ])
      ifTrue: [ key := key first ].

There key first returns a comma separated string. The first part of this string is a key contained by #continuations and the second part is an url. This only happens, when two sessions runs at the same time. If the two sessions run one after another nothing special appears.

So I overwrote #handleFiltered: in my own subclass:

Code: Select all

handleFiltered: aRequestContext

   | key continuation |

   key :=
      aRequestContext request fields
         at: self actionField
         ifAbsent: [^self start].

   (key isString not and: [key isSequenceable ])
      ifTrue: [key := (key first subStrings: $,) first].
      
   continuation :=
      continuations
         at: key
         ifAbsent: [^self unknownRequest ].
         
   continuation value

Now the continuation at the key is found and the app will continue as expected. But only the last triggered session. The first session ist stopped with a blank screen. When I hit return, this session continues..

I have two different sessions with two different presenters, but it seems that there is a point in Seaside, that couldn't seperate this two sessions, when they're running simultaneously.

During my researches I found in the Squeak Seaside Forum an analogue problem http://n4.nabble.com/Multiple-Browser-Tabs-on-Same-Application-td947917.html#a947917

Regards

Klaus

[klaus]

Hello,

the problem still exists in VA 8.0.2. Some additional informations:

In #WASession->#handleFiltered: are some strange keys generated like this:
'dMoQn19oI0iCf-hU,/myurl/myview?_s=zQNEY3K8-r2tAQB0'
I think the first part before the comma is the correct key. But with this key #WASession->#unknownRequest is called.

If both request are finished, the url in the browser of the second session looks like:
http://localhost:4711/myurl/myview?_s=qT-_4Wq5xQmkANyi&_k=VgCZePTYqgUaCTC6, /myurl/myview?_s=9nrG8deFoBo3SrxU&_k=qLBl242xtjYnj-1T

The browser's url of the first session looks then:
http://localhost:4711/myurl/myview?_s=qT-_4Wq5xQmkANyi&_k=Lfcd1lxzuKYNrgx4

What happened there? Why the first session is captured by the browser of the second session?

Kind regards

Klaus

[marten]

Hello,

the problem still exists in VA 8.0.2. Some additional informations:

Any new information about this - I was actually writing my first Seaside demo. Then I tried a hard test and did a wild clickering on my application and I (very) easily get an error like this (unknown request) over the time ... (all here in 8.0.2)

[klaus]

Any new information about this - I was actually writing my first Seaside demo. Then I tried a hard test and did a wild clickering on my application and I (very) easily get an error like this (unknown request) over the time ... (all here in 8.0.2)

Hi Marten,

due to a novemberrelease I did not found time to research deeper into this problem. But in 2 weeks I' ll have this time. Strange but I'm glad to see that another user has a simular problem

I think, that this problem is based on the unfinished continuation implementation in VA Smalltalk.

Regards

Klaus

[TriSebastian]

Hi Klaus, Marten, Joachim,

It seems to me like there's some problem with the exceptionhandling in general.
I also had this problem. But in my case it was just a result from an error that occured somewhere else in the codeing.
I subclassed a Interface class of my WAComponents and didn't overwrite a something ^self subclassResponsibility method wrong (typo...).
The Exception thrown by subclassResponsibility was handled by the exception handling in those methods around handleFiltered:
In my case a got different results from this. Current WARequestContext was nil, or as you guys already mentioned _k or _s field were missing in the continuation related methods, and so on....
Funny this was that. When I terminated the Exception Process Stack and refreshed my seaside site I got two Stacktraces. One including the same content as the Error befor the other contained a stackoverflow happening during a String operation. But in this case there was no bug...
I have no idea how I found out about my subclassResponsibility bug, but when I solved it everything worked fine again.

Just to make sure... did you guys change the Ecxeption forwarding in SST? Transcript->Tools(I think)->SST ->forward/trap/...
Just forward everything...

As far as I found out the problem isn't a missing Session or Context information. It is a Exception handling problem...

Best Regards
Sebastian

[klaus]

Hi Sebastian,

your hint for #subclassResponsibilty works my sessions run now isolated. But not really
The second started session works as expected and displays the result screen. But the first session stops with a white display in the browser - regardless if Opera or Firefox - If I hit enter in the url line, then this session shows the expected screen with the results.

Url with the white screen:
koelnisch-wasser:4711/dingens/gedoehns?_s=hmM7Hu-LcxOADkX1&_k=xEiCI25TfeJu7bwc

Url when I hit enter:
koelnisch-wasser:4711/dingens/gedoehns?_s=hmM7Hu-LcxOADkX1&_k=-f-7AUxwlJRcLgf1

Why this session stops?

I ran QA Tools on GRObject and all subclasses and eliminated all my #subclassResponsibilty errors. But there are a few other owned by Seaside for VA Smalltalk.

Regards

Klaus

[marten]

Just to make sure... did you guys change the Ecxeption forwarding in SST? Transcript->Tools(I think)->SST ->forward/trap/...
Just forward everything...

That's lead me to a new beginner question about Seaside for VASmalltalk - how can I get "normal" debugging behaviour: how do I have to configure SST (forward exception - I did that) and Seaside in that way, that the debugger stops where the error happens and not always somewhere around session handling.

[jtuchel]

Marten,

you need to configure your seaside application's error handler:

http://joachimtuchel.wordpress.com/2009/12/11/vast-8-0-1-seaside-tips-registering-an-error-handler-in-your-application/

Joachim

[jtuchel]

Hi Klaus, Marten, Joachim,

As far as I found out the problem isn't a missing Session or Context information. It is a Exception handling problem...

Best Regards
Sebastian

Sebastian,

this explains why I never saw this problem. Luckily, most of my forgotten overrides are missing super calls to initialize in my components, but it seems I never forgot to implement a subclassResponsibility...

Could you / did you take the time to verify if this is just any subclassResponsibility, or only in certain Seaside classes?

Most of all: thanks for your time looking into this.

Joachim

[TriSebastian]

Moin!

Joachim, no, I didn't specify this. In my case it was just a subclassResponsibilty in one of my classes and this was in deed a "Seaside"-class. Tahnks for your blog post. I'll have a look!

Klaus, could it be that you have some lazy initialization in your codeing that makes the first session fail? or could it be that you forgot to implement a "super initialize " in one of your initialize methods?
Could it also be that your whole Datamodel, or Seaside--Component-Model hat a little bug somewhere? An exception you will only get during the first Session initialization, or the very first initialization of your application?

Marten, all, John proved me wrong with this SSt: Trap/Frowarding thing. It seems like this will no longer be necessary with VAST 8.0.2. So please forget about that. Thanks, John.

While I was searching for my bug, I saw one line of codeing that grabbed the first available session,... but I' not sure where it was. I'll need to have a look again. Maybe this is also a potential thing for this strange session behavior. I'm only wondering why other dialects seem not to report such problems. There must be something different with SST as opposed to WAKom and Swazoo...

I'll have a look this evening.

Sebastian

[jtuchel]

Sebastian,

the link to the blog post was an answer to Marten, and may not be of any interest for you

I must say I sometimes see problems in Seaside and wonder why they are in VAST only. Most of the times, copying the code to Pharo showed it's working, but it also almost always was an error somewhere in my coding rather than in VAST's Seaside implementation. Or it was me using a method that needs Continuations.

Joachim