I'm occasionally seeing WATree>>itemStack return nil during runtime. This is resulting in a walkback, although it happens rarely. This is for my wife's site:
It just happened again, and so I know a customer got a walkback in their browser. When I went into the debugger, I could see that this customer had two items in their cart. Hence, this potentially lost us a sale. They hadn't yet completed the portion of "checkout" where they enter their contact info, so I don't know who it was.
It doesn't happen very often, but I've seen it before.
Nevin
Hi Nevin,
I noticed in 2.3b there's a component called WAComponentTree. That might be a newer version of WATree.
Derek Brans Nerd on a Wire Web design that's anything but square http://www.nerdonawire.com phone: 604.874.6463 mailto: brans@nerdonawire.com
----- Original Message ----- From: "Nevin Pratt" nevin@smalltalkpro.com To: seaside@lists.squeakfoundation.org Sent: Tuesday, April 22, 2003 6:52 PM Subject: [Seaside] WATree itemStack returning nil
I'm occasionally seeing WATree>>itemStack return nil during runtime. This is resulting in a walkback, although it happens rarely. This is for my wife's site:
It just happened again, and so I know a customer got a walkback in their browser. When I went into the debugger, I could see that this customer had two items in their cart. Hence, this potentially lost us a sale. They hadn't yet completed the portion of "checkout" where they enter their contact info, so I don't know who it was.
It doesn't happen very often, but I've seen it before.
Nevin
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Wed, 23 Apr 2003, Derek Brans wrote:
Hi Nevin,
I noticed in 2.3b there's a component called WAComponentTree. That might be a newer version of WATree.
Nope. It's used to display the current tree of subcomponents - when you click Inspect on the toolbar, for example, this'll let you choose which subcomponent you actually want to look at.
It's somewhat broken right now, though - I know, for example, that it doesn't detect cycles, so if your subcomponents have parent references, using the ComponentTree leads to infinite recursion.
Nevin, as for your problems with WATree - do you happen to have any way for me to reproduce the bug?
Avi
Avi Bryant wrote:
Nevin, as for your problems with WATree - do you happen to have any way for me to reproduce the bug?
Avi
No. I almost *never* see it. However, I saw it again about an hour ago. Where I see it is in one of my components that holds a WATree. My component's #renderContentOn: method asks the tree for it's current selection (which happens to be an item category-- an instance of ItemCategory), and then fetches and displays items that are for sale within that category.
I think it's possible that the probelem is not in your code. One thought that crossed my mind is when I'm hot-swapping item categories (reinitializing and/or reloading from the database), there might be some WATree's from lingering component instances that are getting confused.
I have a custom subclass of WASession, called BBSession, basically just for handling the shopping cart. I'll probably just override #handleError: to do something simple when an error is detected, and otherwise just ignoring the WATree issue for now.
Nevin
Nevin Pratt wrote:
I have a custom subclass of WASession, called BBSession, basically just for handling the shopping cart. I'll probably just override #handleError: to do something simple when an error is detected, and otherwise just ignoring the WATree issue for now.
Nevin
I've put in BBSession>>handleError: to email me a stack trace, and then just redirect to the home page. I'll see what email messages I get now :-)
Nevin
Nevin wrote:
I think it's possible that the probelem is not in your code. One thought that crossed my mind is when I'm hot-swapping item categories (reinitializing and/or reloading from the database), there might be some WATree's from lingering component instances that are getting confused.
Nevin also wrote:
I've put in BBSession>>handleError: to email me a stack trace, and then just redirect to the home page. I'll see what email messages I get now :-)
Nevin
I'm starting to think (again) it really *is* a WATree problem. I'm getting about one email message a day. They always have the same basic stack trace (different 'anItem' values for WATree>>select:, not just '#321-Girls Clothes', to reflect the specific item category of the WATree the user selected). I haven't been playing with the item categories for awhile, and I still get about one error a day.
Based on the page that has the WATree, this represents about 1% of the WATree accesses generating the error. Here is the stack trace (this is in html, so hopefully your email reader reads html).
I might have to dig in and figure out how your WATree (and associated classes) really work, so I can debug this thing.
Nevin
MessageNotUnderstood: includes:
* UndefinedObject(Object)>>doesNotUnderstand:
self nil aMessage a Message with selector: #includes: and arguments: #(#321-Girls Clothe...etc...
* WATree>>select:
self a WATree anItem #321-Girls Clothes
* [] in WATree>>renderContentOn:
self a WATree html a WAHtmlRenderer item #21-Baby Boutique child #321-Girls Clothes
* WACallbackStore>>processRequest:
self a WACallbackStore aRequest a WARequest assoc '12'->''
* WAHtmlRenderer>>renderResponse:
self a WAHtmlRenderer aBlock [] in WAFrame(WAComponent)>>respond req a WARequest url nil
* WAFrame(WAComponent)>>respond
self a WAFrame renderer nil
* WAFrame(WAComponent)>>start
self a WAFrame
* BBIndex class(WAComponent class)>>start
self BBIndex
* [] in BBSession(WASession)>>start
self a BBSession
* BlockContext>>on:do:
self [] in BBSession(WASession)>>start exception Error handlerAction [] in BBSession(WASession)>>do: handlerActive false
* [] in BBSession(WASession)>>do:
self a BBSession aBlock [] in BBSession(WASession)>>start e nil n a WACurrentSessionNotification
* BlockContext>>on:do:
self [] in BBSession(WASession)>>do: exception WACurrentSessionNotification handlerAction [] in BBSession(WASession)>>do: handlerActive true
* BBSession(WASession)>>do:
self a BBSession aBlock [] in BBSession(WASession)>>start e nil n a WACurrentSessionNotification
* BBSession(WASession)>>start
self a BBSession
* BBSession(WASession)>>performRequest:
self a BBSession aRequest a WARequest continuation nil
* [] in BBSession(WASession)>>responseForRequest:
self a BBSession aRequest a WARequest cc a Continuation
* Continuation class>>currentDo:
self Continuation aBlock [] in BBSession(WASession)>>responseForRequest:
* BBSession(WASession)>>responseForRequest:
self a BBSession aRequest a WARequest cc a Continuation
* [] in BBSession(WASession)>>handleRequest:
self a BBSession aRequest a WARequest
* [] in WAProcessMonitor>>do:
self a WAProcessMonitor aBlock [] in BBSession(WASession)>>handleRequest: value a WAResponse
* [] in BlockContext>>newProcess
self [] in WAProcessMonitor>>do:
Nevin Pratt wrote:
I'm starting to think (again) it really *is* a WATree problem. I'm getting about one email message a day.
I've gotten *six* stack walkbacks today.
And, I've now got a Netscape bookmark that reliably brings up a page that when I click on one of the WATree children, the problem occurs (I don't know what magic occured to produce the trouble bookmark, because I haven't been able to create a second one, but at least I have one now).
But, it looks like this is a problem related with some interaction between the WATree and the way Seaside keeps state. And, the problem *might* only occur when a user bookmarks a page and tries to come back to it later.
You would think that since I can reliably *cause* the problem now (via the Netscape bookmark), I should be able to bring up the debugger and it would be easy to find and fix the problem. Unfortunately, the way Seaside does context tricks makes it so this problem isn't as easy to debug as most Smalltalkers might think. It's a mystery to me what is going on.
Here's something that is odd:
1. I insert a 'self inspect' inside the middle of WATree>>renderContentOn: 2. I use my Netscape "Bookmark" to bring up the trouble page. (an inspector on a WATree instance pops up, as expected) 3. I evaluate 'self children' inside of the WATree inspector that popped up. (I get an inspector on a collection of children, as expected. And, those children match the children shown in the NetScape bookmarked page) 4. I go back to the Netscape page and click on one of the children. (the browser shows a stack walkback because the error occurs)
Hmm, so what happened? Well, lets go back to the Smalltalk-side of things:
5. I come back to the WATree inspector window that I previously evaluated the 'self children' and just evaluate the expression again, and there are no children this time. Well, at least I don't *think* there are children, as the itemStack is now a StateHolder(nil), and 'self itemStack' brings back nil. ('self children' actually errors out with a DNU because the itemStack is nil).
I'm going to keep poking around to see if I can figure this out, but if anybody has any ideas...
Nevin
On Mon, 28 Apr 2003, Nevin Pratt wrote:
And, I've now got a Netscape bookmark that reliably brings up a page that when I click on one of the WATree children, the problem occurs (I don't know what magic occured to produce the trouble bookmark, because I haven't been able to create a second one, but at least I have one now).
But, it looks like this is a problem related with some interaction between the WATree and the way Seaside keeps state. And, the problem *might* only occur when a user bookmarks a page and tries to come back to it later.
It does sound like it's a problem with the state management. If that's what it is, the problem almost certainly only occurs when the user hits the same URL twice, either by using the backbutton or by bookmarking.
I should point out that the state management changed from 2.2 to 2.3, partly because the 2.2 scheme was somewhat error prone. So it's extremely likely that you wouldn't have seen this problem if you'd kept your 2.3 port (I know, you were seeing other problems - remind me exactly why you moved back to 2.2?)
At any rate, I'll take a look at WATree under 2.2 later tonight and see if I can reproduce (and hopefully fix) the problem. Can you give me any more details about what patterns of usage seem to cause it?
Avi
Avi Bryant wrote:
So it's extremely likely that you wouldn't have seen this problem if you'd kept your 2.3 port (I know, you were seeing other problems - remind me exactly why you moved back to 2.2?)
With 2.3a, pages would occasionally not load/refresh properly. The browser window would be completely blank, and I would have to manually hit the browser "Refresh" button to see the page.
And, I've never seen that problem with 2.2.
Nevin
On Mon, 28 Apr 2003, Nevin Pratt wrote:
With 2.3a, pages would occasionally not load/refresh properly. The browser window would be completely blank, and I would have to manually hit the browser "Refresh" button to see the page.
And, I've never seen that problem with 2.2.
Ok, I thought that was it. I've now managed to reproduce that, but only on OS X, and only using Safari - not, for example, using ab (apache bench) to throw hundreds of concurrent connections at it. All I've noticed so far is that the requests with blank responses don't even make it to Comanche - somehow the connection gets dropped by Squeak very early on. How this would be connected in any way to the version of Seaside, Seaside vs. other Comanche modules, and so on, I don't yet know...
Avi
Avi Bryant wrote:
On Mon, 28 Apr 2003, Nevin Pratt wrote:
With 2.3a, pages would occasionally not load/refresh properly. The browser window would be completely blank, and I would have to manually hit the browser "Refresh" button to see the page.
And, I've never seen that problem with 2.2.
Ok, I thought that was it. I've now managed to reproduce that, but only on OS X, and only using Safari - not, for example, using ab (apache bench) to throw hundreds of concurrent connections at it. All I've noticed so far is that the requests with blank responses don't even make it to Comanche - somehow the connection gets dropped by Squeak very early on. How this would be connected in any way to the version of Seaside, Seaside vs. other Comanche modules, and so on, I don't yet know...
Avi
OSX/Safari as the client (only)? Or is Squeak running on OSX too?
If you remember, I wasn't the only one to encounter the load/refresh problem. But, it sounds like VM differences just might be accounting for the result differences.
Perhaps I need to look and see what the latest Linux/86 VM is now.
Nevin
Hmm... this just rung a bell for me. I was setting up a demo using the new seaside last week on OSX (the server and the client) and I was seeing blank pages sometimes that would be fine if I hit refresh. I don't think it was browser dependant, though I can't quite remember which browsers I was using.
Julian
Avi Bryant wrote:
On Mon, 28 Apr 2003, Nevin Pratt wrote:
With 2.3a, pages would occasionally not load/refresh properly. The browser window would be completely blank, and I would have to manually hit the browser "Refresh" button to see the page.
And, I've never seen that problem with 2.2.
Ok, I thought that was it. I've now managed to reproduce that, but only on OS X, and only using Safari - not, for example, using ab (apache bench) to throw hundreds of concurrent connections at it. All I've noticed so far is that the requests with blank responses don't even make it to Comanche - somehow the connection gets dropped by Squeak very early on. How this would be connected in any way to the version of Seaside, Seaside vs. other Comanche modules, and so on, I don't yet know...
Avi
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Nevin Pratt wrote:
With 2.3a, pages would occasionally not load/refresh properly. The browser window would be completely blank, and I would have to manually hit the browser "Refresh" button to see the page.
And, I've never seen that problem with 2.2.
Nevin
Incidentally, I want to again reiterate that I am extremely grateful for your work with Seaside. As I reread my posts, I feel like they have an air of "complaining", and yet Seaside is, in my opinion, a real piece of genious work. Any piece of software has problems, and yet Seaside has been quite stable overall (even if my posts might appear otherwise sometimes).
Overall, I am *very* happy with it.
Thanks guys,
Nevin
Nevin Pratt wrote:
I've gotten *six* stack walkbacks today.
And, I've now got a Netscape bookmark that reliably brings up a page that when I click on one of the WATree children, the problem occurs (I don't know what magic occured to produce the trouble bookmark, because I haven't been able to create a second one, but at least I have one now).
Hmm, the bookmark's no longer generating the error.
Just ignore me until I've got something concrete.
Nevin
seaside@lists.squeakfoundation.org
-
Avi Bryant -
Derek Brans -
Julian Fitzell -
Nevin Pratt