Smalltalk › Gemtalk › GLASS

GemSource, seaside.gemstone.com, SS3 MAINTENANCE Saturday June 9 from 10am-2pm PDT

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

19 messages Options

Dale Henrichs

GemSource, seaside.gemstone.com, SS3 MAINTENANCE Saturday June 9 from 10am-2pm PDT

Maintenance is scheduled for this Saturday and according to the internal announcement no downtime is anticipated:

The work is considered low risk and no downtime is
anticipated, this is being sent out as a courtesy.

If you experience problems on Saturday, don't hesitate to send email.

Dale

Larry Kellogg

Session user nil problem

Hello,

So, I have defined a subclass of WASession which has an instance variable named 'user'. When a user logs into

my system, I set the user instance variable to the logged in user. This all works great. All of the subclasses of WAComponent

fetch the logged in user by sending 'self session user'.

Like I said, everything works fine except that I am getting some walkbacks from a few WAComponent views where

the user is nil. I don't understand how the user can be set to nil on the session if the user is logged in and one of my views is being displayed.

Any thoughts?

Larry

Dale Henrichs

Re: Session user nil problem

Some questions to clear the decks for further exploration:

Do you do explicit GemStone aborts or commits in your
code?

Do you use allInstances (or a variant) in your code.
This could cause a commit to be performed.

Outside of these "spurious" transactions, the only other thing I can think of is that there might be a path through session creation that doesn't set the user? A timeout perhaps or something along those lines?

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Friday, June 15, 2012 3:49:07 PM
| Subject: [GS/SS Beta] Session user nil problem
|
| Hello,
| So, I have defined a subclass of WASession which has an instance
| variable named 'user'. When a user logs into
| my system, I set the user instance variable to the logged in user.
| This all works great. All of the subclasses of WAComponent
| fetch the logged in user by sending 'self session user'.
|
|
| Like I said, everything works fine except that I am getting some
| walkbacks from a few WAComponent views where
| the user is nil. I don't understand how the user can be set to nil on
| the session if the user is logged in and one of my views is being
| displayed.
|
|
| Any thoughts?
|
|
| Larry

Larry Kellogg

Re: Session user nil problem

Hello Dale,

On Jun 15, 2012, at 7:16 PM, Dale Henrichs wrote:

> Some questions to clear the decks for further exploration:
>
> Do you do explicit GemStone aborts or commits in your
> code?
>

No, I do not.

> Do you use allInstances (or a variant) in your code.
> This could cause a commit to be performed.
>

I don't use allInstances, as far as I recall.

> Outside of these "spurious" transactions, the only other thing I can think of is that there might be a path through session creation that doesn't set the user? A timeout perhaps or something along those lines?

Yes, I'm wondering what happens during a timeout. I'll have to look for other paths that wouldn't set user. It's a mystery to me.

Any chance that this messes me up:

createCache
"To configure the continuation cache you must currently subclass WASession and override this method."
| policy |
policy := WARcLastAccessExpiryPolicy new.
policy configuration at: #cacheTimeout put: 1200.
^ WACache new
setExpiryPolicy: policy;
yourself.

??

Thanks,

Larry

Jon Paynter-2

Re: Session user nil problem

Lary,
well here is what I would try
(I use the same pattern in regular seaside)
first off - put a test for nil in the setter for user in your session class - that will catch the obvious issue of an explicit setting.

Next - when you do find the user nil - check the session class on your component and make sure its an instance of your session and not something else (or an older version of your session class).

Then in the components where the problem happens, check your initialize method (and that of the superclasses) to make sure everyone in the hierarchy chain is sending #super initialize

Lastly - is this reproduceable? or is it random?

On Fri, Jun 15, 2012 at 4:20 PM, Lawrence Kellogg <[hidden email]> wrote:

Hello Dale,

On Jun 15, 2012, at 7:16 PM, Dale Henrichs wrote:

> Some questions to clear the decks for further exploration:
>
> Do you do explicit GemStone aborts or commits in your
> code?
>

No, I do not.

> Do you use allInstances (or a variant) in your code.
> This could cause a commit to be performed.
>

I don't use allInstances, as far as I recall.

> Outside of these "spurious" transactions, the only other thing I can think of is that there might be a path through session creation that doesn't set the user? A timeout perhaps or something along those lines?

Yes, I'm wondering what happens during a timeout. I'll have to look for other paths that wouldn't set user. It's a mystery to me.

Any chance that this messes me up:

createCache
"To configure the continuation cache you must currently subclass WASession and override this method."
| policy |
policy := WARcLastAccessExpiryPolicy new.
policy configuration at: #cacheTimeout put: 1200.
^ WACache new
setExpiryPolicy: policy;
yourself.

??

Thanks,

Larry

>
> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Friday, June 15, 2012 3:49:07 PM
> | Subject: [GS/SS Beta] Session user nil problem
> |
> | Hello,
> | So, I have defined a subclass of WASession which has an instance
> | variable named 'user'. When a user logs into
> | my system, I set the user instance variable to the logged in user.
> | This all works great. All of the subclasses of WAComponent
> | fetch the logged in user by sending 'self session user'.
> |
> |
> | Like I said, everything works fine except that I am getting some
> | walkbacks from a few WAComponent views where
> | the user is nil. I don't understand how the user can be set to nil on
> | the session if the user is logged in and one of my views is being
> | displayed.
> |
> |
> | Any thoughts?
> |
> |
> | Larry

Dale Henrichs

Re: Session user nil problem

In reply to this post by Larry Kellogg

Larry Kellogg

Re: Session user nil problem

In reply to this post by Jon Paynter-2

On Jun 15, 2012, at 7:27 PM, Jon Paynter wrote:

Lary,
well here is what I would try
(I use the same pattern in regular seaside)
first off - put a test for nil in the setter for user in your session class - that will catch the obvious issue of an explicit setting.

Next - when you do find the user nil - check the session class on your component and make sure its an instance of your session and not something else (or an older version of your session class).

Then in the components where the problem happens, check your initialize method (and that of the superclasses) to make sure everyone in the hierarchy chain is sending #super initialize

Good point! I will check my initialize methods.

Lastly - is this reproduceable? or is it random?

Thanks, John, I will try out the things that you mentioned. I have not been able to reproduce this problem, I've never

seen it. Everyone once in a while, I get some continuations from my users. I'm kind of stumped as to what is going on.

Larry

On Fri, Jun 15, 2012 at 4:20 PM, Lawrence Kellogg <[hidden email]> wrote:
Hello Dale,

On Jun 15, 2012, at 7:16 PM, Dale Henrichs wrote:

> Some questions to clear the decks for further exploration:
>
> Do you do explicit GemStone aborts or commits in your
> code?
>

No, I do not.

> Do you use allInstances (or a variant) in your code.
> This could cause a commit to be performed.
>

I don't use allInstances, as far as I recall.

> Outside of these "spurious" transactions, the only other thing I can think of is that there might be a path through session creation that doesn't set the user? A timeout perhaps or something along those lines?

Yes, I'm wondering what happens during a timeout. I'll have to look for other paths that wouldn't set user. It's a mystery to me.

Any chance that this messes me up:

createCache
"To configure the continuation cache you must currently subclass WASession and override this method."
| policy |
policy := WARcLastAccessExpiryPolicy new.
policy configuration at: #cacheTimeout put: 1200.
^ WACache new
setExpiryPolicy: policy;
yourself.

??

Thanks,

Larry

>
> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Friday, June 15, 2012 3:49:07 PM
> | Subject: [GS/SS Beta] Session user nil problem
> |
> | Hello,
> | So, I have defined a subclass of WASession which has an instance
> | variable named 'user'. When a user logs into
> | my system, I set the user instance variable to the logged in user.
> | This all works great. All of the subclasses of WAComponent
> | fetch the logged in user by sending 'self session user'.
> |
> |
> | Like I said, everything works fine except that I am getting some
> | walkbacks from a few WAComponent views where
> | the user is nil. I don't understand how the user can be set to nil on
> | the session if the user is logged in and one of my views is being
> | displayed.
> |
> |
> | Any thoughts?
> |
> |
> | Larry

Larry Kellogg

Re: Session user nil problem

In reply to this post by Dale Henrichs

On Jun 15, 2012, at 7:37 PM, Dale Henrichs wrote:

> Nothing suspicious or obviously wrong there ... at least we can rule them out as we move forward:)
>
> I'm foggy on the details of session timeout, so there might be something unexpected going on when a session is timed out with an active component visible?
>
> Do you have an independent means to determine if the session is logged in or do you use the session variable for that?
>

I use the session variable. I expect a user to be logged in when displaying any subclasses of WAComponent.

Larry

> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Friday, June 15, 2012 4:20:19 PM
> | Subject: Re: [GS/SS Beta] Session user nil problem
> |
> | Hello Dale,
> |
> | On Jun 15, 2012, at 7:16 PM, Dale Henrichs wrote:
> |
> | > Some questions to clear the decks for further exploration:
> | >
> | > Do you do explicit GemStone aborts or commits in your
> | > code?
> | >
> |
> | No, I do not.
> |
> |
> | > Do you use allInstances (or a variant) in your code.
> | > This could cause a commit to be performed.
> | >
> |
> | I don't use allInstances, as far as I recall.
> |
> | > Outside of these "spurious" transactions, the only other thing I
> | > can think of is that there might be a path through session
> | > creation that doesn't set the user? A timeout perhaps or something
> | > along those lines?
> |
> | Yes, I'm wondering what happens during a timeout. I'll have to look
> | for other paths that wouldn't set user. It's a mystery to me.
> |
> | Any chance that this messes me up:
> |
> | createCache
> | "To configure the continuation cache you must currently subclass
> | WASession and override this method."
> | | policy |
> | policy := WARcLastAccessExpiryPolicy new.
> | policy configuration at: #cacheTimeout put: 1200.
> | ^ WACache new
> | setExpiryPolicy: policy;
> | yourself.
> |
> | ??
> |
> | Thanks,
> |
> | Larry
> |
> |
> |
> | >
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | To: "GemStone Seaside beta discussion"
> | > | <[hidden email]>
> | > | Sent: Friday, June 15, 2012 3:49:07 PM
> | > | Subject: [GS/SS Beta] Session user nil problem
> | > |
> | > | Hello,
> | > | So, I have defined a subclass of WASession which has an instance
> | > | variable named 'user'. When a user logs into
> | > | my system, I set the user instance variable to the logged in
> | > | user.
> | > | This all works great. All of the subclasses of WAComponent
> | > | fetch the logged in user by sending 'self session user'.
> | > |
> | > |
> | > | Like I said, everything works fine except that I am getting some
> | > | walkbacks from a few WAComponent views where
> | > | the user is nil. I don't understand how the user can be set to
> | > | nil on
> | > | the session if the user is logged in and one of my views is being
> | > | displayed.
> | > |
> | > |
> | > | Any thoughts?
> | > |
> | > |
> | > | Larry
> |
> |

Larry Kellogg

Re: Session user nil problem

In reply to this post by Larry Kellogg

On Jun 15, 2012, at 8:12 PM, Lawrence Kellogg wrote:

On Jun 15, 2012, at 7:27 PM, Jon Paynter wrote:

Lary,
well here is what I would try
(I use the same pattern in regular seaside)
first off - put a test for nil in the setter for user in your session class - that will catch the obvious issue of an explicit setting.

Next - when you do find the user nil - check the session class on your component and make sure its an instance of your session and not something else (or an older version of your session class).

Well, I am setting the user to nil when a user logs out. Perhaps that is causing a problem. I took that line out for now.

Could that be the issue? The system returns to the LoginView so I'm not sure why setting the user to nil would cause a problem

because the user is going to have to log in with again in order to set the user to something else.

Then in the components where the problem happens, check your initialize method (and that of the superclasses) to make sure everyone in the hierarchy chain is sending #super initialize

Good point! I will check my initialize methods.

Lastly - is this reproduceable? or is it random?

Thanks, John, I will try out the things that you mentioned. I have not been able to reproduce this problem, I've never
seen it. Everyone once in a while, I get some continuations from my users. I'm kind of stumped as to what is going on.

Larry

On Fri, Jun 15, 2012 at 4:20 PM, Lawrence Kellogg <[hidden email]> wrote:
Hello Dale,

On Jun 15, 2012, at 7:16 PM, Dale Henrichs wrote:

> Some questions to clear the decks for further exploration:
>
> Do you do explicit GemStone aborts or commits in your
> code?
>

No, I do not.

> Do you use allInstances (or a variant) in your code.
> This could cause a commit to be performed.
>

I don't use allInstances, as far as I recall.

> Outside of these "spurious" transactions, the only other thing I can think of is that there might be a path through session creation that doesn't set the user? A timeout perhaps or something along those lines?

Yes, I'm wondering what happens during a timeout. I'll have to look for other paths that wouldn't set user. It's a mystery to me.

Any chance that this messes me up:

createCache
"To configure the continuation cache you must currently subclass WASession and override this method."
| policy |
policy := WARcLastAccessExpiryPolicy new.
policy configuration at: #cacheTimeout put: 1200.
^ WACache new
setExpiryPolicy: policy;
yourself.

??

Thanks,

Larry

>
> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Friday, June 15, 2012 3:49:07 PM
> | Subject: [GS/SS Beta] Session user nil problem
> |
> | Hello,
> | So, I have defined a subclass of WASession which has an instance
> | variable named 'user'. When a user logs into
> | my system, I set the user instance variable to the logged in user.
> | This all works great. All of the subclasses of WAComponent
> | fetch the logged in user by sending 'self session user'.
> |
> |
> | Like I said, everything works fine except that I am getting some
> | walkbacks from a few WAComponent views where
> | the user is nil. I don't understand how the user can be set to nil on
> | the session if the user is logged in and one of my views is being
> | displayed.
> |
> |
> | Any thoughts?
> |
> |
> | Larry

Jon Paynter-2

Re: Session user nil problem

Well nil on logout makes logical sense. I wouldn't change that.

but since your having trouble reproducing it yourself, id put in some logging to see if you can catch it while the users are working.

Another thing you can try - is if the user does come up nil, force them to log in again. that may work in that the users will tell you what they did, or that my backfire in that they will complain about having to re-log in.

debugging these intermittent problems is why they pay us the big $$. good luck!

On Sat, Jun 16, 2012 at 8:40 AM, Lawrence Kellogg <[hidden email]> wrote:

On Jun 15, 2012, at 8:12 PM, Lawrence Kellogg wrote:

On Jun 15, 2012, at 7:27 PM, Jon Paynter wrote:

Lary,
well here is what I would try
(I use the same pattern in regular seaside)
first off - put a test for nil in the setter for user in your session class - that will catch the obvious issue of an explicit setting.

Next - when you do find the user nil - check the session class on your component and make sure its an instance of your session and not something else (or an older version of your session class).

Well, I am setting the user to nil when a user logs out. Perhaps that is causing a problem. I took that line out for now.
Could that be the issue? The system returns to the LoginView so I'm not sure why setting the user to nil would cause a problem

because the user is going to have to log in with again in order to set the user to something else.

Then in the components where the problem happens, check your initialize method (and that of the superclasses) to make sure everyone in the hierarchy chain is sending #super initialize

Good point! I will check my initialize methods.

Lastly - is this reproduceable? or is it random?

Thanks, John, I will try out the things that you mentioned. I have not been able to reproduce this problem, I've never
seen it. Everyone once in a while, I get some continuations from my users. I'm kind of stumped as to what is going on.

Larry

On Fri, Jun 15, 2012 at 4:20 PM, Lawrence Kellogg <[hidden email]> wrote:

Hello Dale,

On Jun 15, 2012, at 7:16 PM, Dale Henrichs wrote:

> Some questions to clear the decks for further exploration:
>
> Do you do explicit GemStone aborts or commits in your
> code?
>

No, I do not.

> Do you use allInstances (or a variant) in your code.
> This could cause a commit to be performed.
>

I don't use allInstances, as far as I recall.

> Outside of these "spurious" transactions, the only other thing I can think of is that there might be a path through session creation that doesn't set the user? A timeout perhaps or something along those lines?

Yes, I'm wondering what happens during a timeout. I'll have to look for other paths that wouldn't set user. It's a mystery to me.

Any chance that this messes me up:

createCache
"To configure the continuation cache you must currently subclass WASession and override this method."
| policy |
policy := WARcLastAccessExpiryPolicy new.
policy configuration at: #cacheTimeout put: 1200.
^ WACache new
setExpiryPolicy: policy;
yourself.

??

Thanks,

Larry

>
> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Friday, June 15, 2012 3:49:07 PM
> | Subject: [GS/SS Beta] Session user nil problem
> |
> | Hello,
> | So, I have defined a subclass of WASession which has an instance
> | variable named 'user'. When a user logs into
> | my system, I set the user instance variable to the logged in user.
> | This all works great. All of the subclasses of WAComponent
> | fetch the logged in user by sending 'self session user'.
> |
> |
> | Like I said, everything works fine except that I am getting some
> | walkbacks from a few WAComponent views where
> | the user is nil. I don't understand how the user can be set to nil on
> | the session if the user is logged in and one of my views is being
> | displayed.
> |
> |
> | Any thoughts?
> |
> |
> | Larry

Larry Kellogg

Re: Session user nil problem

On Jun 16, 2012, at 2:44 PM, Jon Paynter wrote:

Well nil on logout makes logical sense. I wouldn't change that.

Yeah, I agree, I don't see how that is causing a problem.

but since your having trouble reproducing it yourself, id put in some logging to see if you can catch it while the users are working.
Another thing you can try - is if the user does come up nil, force them to log in again. that may work in that the users will tell you what they did, or that my backfire in that they will complain about having to re-log in.

Jon,

So, I put in code in the accessor for user so that if it ever comes up nil, I do the effect of the logout which is to do 'self answer: nil' but I really don't know

how Seaside is going to handle this case. There are a lot of calls to self user in the code, so I don't want to go through and check every single one.

How is Seaside going to handle coming across that self answer? Seems like a bad idea. What do you think?

My experience with users has been that it is very difficult to get them to tell you what they're doing. I rarely hear from users, even

when I have continuations that point to an error.

debugging these intermittent problems is why they pay us the big $$. good luck!

Ha ha, the big bucks. I wish.

Larry

On Sat, Jun 16, 2012 at 8:40 AM, Lawrence Kellogg <[hidden email]> wrote:

On Jun 15, 2012, at 8:12 PM, Lawrence Kellogg wrote:

On Jun 15, 2012, at 7:27 PM, Jon Paynter wrote:

Lary,
well here is what I would try
(I use the same pattern in regular seaside)
first off - put a test for nil in the setter for user in your session class - that will catch the obvious issue of an explicit setting.

Next - when you do find the user nil - check the session class on your component and make sure its an instance of your session and not something else (or an older version of your session class).

Well, I am setting the user to nil when a user logs out. Perhaps that is causing a problem. I took that line out for now.
Could that be the issue? The system returns to the LoginView so I'm not sure why setting the user to nil would cause a problem

because the user is going to have to log in with again in order to set the user to something else.

Then in the components where the problem happens, check your initialize method (and that of the superclasses) to make sure everyone in the hierarchy chain is sending #super initialize

Good point! I will check my initialize methods.

Lastly - is this reproduceable? or is it random?

Thanks, John, I will try out the things that you mentioned. I have not been able to reproduce this problem, I've never
seen it. Everyone once in a while, I get some continuations from my users. I'm kind of stumped as to what is going on.

Larry

On Fri, Jun 15, 2012 at 4:20 PM, Lawrence Kellogg <[hidden email]> wrote:

Hello Dale,

On Jun 15, 2012, at 7:16 PM, Dale Henrichs wrote:

> Some questions to clear the decks for further exploration:
>
> Do you do explicit GemStone aborts or commits in your
> code?
>

No, I do not.

> Do you use allInstances (or a variant) in your code.
> This could cause a commit to be performed.
>

I don't use allInstances, as far as I recall.

> Outside of these "spurious" transactions, the only other thing I can think of is that there might be a path through session creation that doesn't set the user? A timeout perhaps or something along those lines?

Yes, I'm wondering what happens during a timeout. I'll have to look for other paths that wouldn't set user. It's a mystery to me.

Any chance that this messes me up:

createCache
"To configure the continuation cache you must currently subclass WASession and override this method."
| policy |
policy := WARcLastAccessExpiryPolicy new.
policy configuration at: #cacheTimeout put: 1200.
^ WACache new
setExpiryPolicy: policy;
yourself.

??

Thanks,

Larry

>
> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Friday, June 15, 2012 3:49:07 PM
> | Subject: [GS/SS Beta] Session user nil problem
> |
> | Hello,
> | So, I have defined a subclass of WASession which has an instance
> | variable named 'user'. When a user logs into
> | my system, I set the user instance variable to the logged in user.
> | This all works great. All of the subclasses of WAComponent
> | fetch the logged in user by sending 'self session user'.
> |
> |
> | Like I said, everything works fine except that I am getting some
> | walkbacks from a few WAComponent views where
> | the user is nil. I don't understand how the user can be set to nil on
> | the session if the user is logged in and one of my views is being
> | displayed.
> |
> |
> | Any thoughts?
> |
> |
> | Larry

Dale Henrichs

Re: Session user nil problem

Lawrence,

Yeah, I would be reluctant to make changes in production code without being sure what was going to happen ...

YOu could simulate scenarios in your sandbox environment and see what happens.

You could also instrument up things a bit more recording stuff in the object log ... you probably don't want the entire session recorded, but you could record the oop of the session (asOop) instead of the session (... be careful playing with oops, referencing an oop will not keep the object alive and therefore the object referenced by an oop could disappear or even come in a different lifetime as a different object, for debugging purposes, the oop is guaranteed to be unique ...) then you record certain events in the log about logins (along with userid), reaping on timeout (again with userid)... if necessary you could snap off a continuation (for later debugging) and stash it or just dump a stack trace ... then when you get a hit for a session that's misbehaving you have a record of it's history that could be used to understand what's going on or where to add more logging ... you can write some log analysis code cade that could be run from topaz or gemtools, or just use the object log tool to surf the object log... it's like print statement debugging only with live objects ...

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Saturday, June 16, 2012 1:19:31 PM
| Subject: Re: [GS/SS Beta] Session user nil problem
|
|
|
|
| On Jun 16, 2012, at 2:44 PM, Jon Paynter wrote:
|
|
| Well nil on logout makes logical sense. I wouldn't change that.
|
|
| Yeah, I agree, I don't see how that is causing a problem.
|
|
|
| but since your having trouble reproducing it yourself, id put in some
| logging to see if you can catch it while the users are working.
| Another thing you can try - is if the user does come up nil, force
| them to log in again. that may work in that the users will tell you
| what they did, or that my backfire in that they will complain about
| having to re-log in.
|
|
|
|
| Jon,
| So, I put in code in the accessor for user so that if it ever comes
| up nil, I do the effect of the logout which is to do 'self answer:
| nil' but I really don't know
| how Seaside is going to handle this case. There are a lot of calls to
| self user in the code, so I don't want to go through and check every
| single one.
| How is Seaside going to handle coming across that self answer? Seems
| like a bad idea. What do you think?
|
|
| My experience with users has been that it is very difficult to get
| them to tell you what they're doing. I rarely hear from users, even
| when I have continuations that point to an error.
|
|
|
| debugging these intermittent problems is why they pay us the big $$.
| good luck!
|
|
|
|
| Ha ha, the big bucks. I wish.
|
|
| Larry
|
|
|
|
| On Sat, Jun 16, 2012 at 8:40 AM, Lawrence Kellogg < [hidden email] >
| wrote:
|
|
|
|
|
|
|
| On Jun 15, 2012, at 8:12 PM, Lawrence Kellogg wrote:
|
|
|
|
|
|
| On Jun 15, 2012, at 7:27 PM, Jon Paynter wrote:
|
|
| Lary,
| well here is what I would try
| (I use the same pattern in regular seaside)
| first off - put a test for nil in the setter for user in your session
| class - that will catch the obvious issue of an explicit setting.
|
| Next - when you do find the user nil - check the session class on
| your component and make sure its an instance of your session and not
| something else (or an older version of your session class).
|
|
|
|
|
|
| Well, I am setting the user to nil when a user logs out. Perhaps that
| is causing a problem. I took that line out for now.
| Could that be the issue? The system returns to the LoginView so I'm
| not sure why setting the user to nil would cause a problem
| because the user is going to have to log in with again in order to
| set the user to something else.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Then in the components where the problem happens, check your
| initialize method (and that of the superclasses) to make sure
| everyone in the hierarchy chain is sending #super initialize
|
|
|
|
| Good point! I will check my initialize methods.
|
|
|
|
|
|
| Lastly - is this reproduceable? or is it random?
|
|
|
|
| Thanks, John, I will try out the things that you mentioned. I have
| not been able to reproduce this problem, I've never
| seen it. Everyone once in a while, I get some continuations from my
| users. I'm kind of stumped as to what is going on.
|
|
| Larry
|
|
|
|
|
|
|
| On Fri, Jun 15, 2012 at 4:20 PM, Lawrence Kellogg < [hidden email] >
| wrote:
|
|
| Hello Dale,
|
|
| On Jun 15, 2012, at 7:16 PM, Dale Henrichs wrote:
|
| > Some questions to clear the decks for further exploration:
| >
| > Do you do explicit GemStone aborts or commits in your
| > code?
| >
|
| No, I do not.
|
|
|
| > Do you use allInstances (or a variant) in your code.
| > This could cause a commit to be performed.
| >
|
| I don't use allInstances, as far as I recall.
|
|
| > Outside of these "spurious" transactions, the only other thing I
| > can think of is that there might be a path through session
| > creation that doesn't set the user? A timeout perhaps or something
| > along those lines?
|
| Yes, I'm wondering what happens during a timeout. I'll have to look
| for other paths that wouldn't set user. It's a mystery to me.
|
| Any chance that this messes me up:
|
| createCache
| "To configure the continuation cache you must currently subclass
| WASession and override this method."
| | policy |
| policy := WARcLastAccessExpiryPolicy new.
| policy configuration at: #cacheTimeout put: 1200.
| ^ WACache new
| setExpiryPolicy: policy;
| yourself.
|
| ??
|
| Thanks,
|
| Larry
|
|
|
|
|
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Lawrence Kellogg" < [hidden email] >
| > | To: "GemStone Seaside beta discussion" <
| > | [hidden email] >
| > | Sent: Friday, June 15, 2012 3:49:07 PM
| > | Subject: [GS/SS Beta] Session user nil problem
| > |
| > | Hello,
| > | So, I have defined a subclass of WASession which has an instance
| > | variable named 'user'. When a user logs into
| > | my system, I set the user instance variable to the logged in
| > | user.
| > | This all works great. All of the subclasses of WAComponent
| > | fetch the logged in user by sending 'self session user'.
| > |
| > |
| > | Like I said, everything works fine except that I am getting some
| > | walkbacks from a few WAComponent views where
| > | the user is nil. I don't understand how the user can be set to
| > | nil on
| > | the session if the user is logged in and one of my views is being
| > | displayed.
| > |
| > |
| > | Any thoughts?
| > |
| > |
| > | Larry
|
|
|
|
|
|
|

Dale Henrichs

ss3.gemstone.com MAINTENANCE Friday September 7 from 2pm-3pm PDT

In reply to this post by Dale Henrichs

ss3.gemstone.com will be down for Maintenance this Friday (September 7) for 1 hour starting at 2pm PDT.

We're fixing a configuration issue (my mistake:).

Dale

Dale Henrichs

ss3.gemstone.com MAINTENANCE Wednesday September 12 from 2pm-3pm PDT

ss3.gemstone.com will be down for Maintenance this Wednesday (September 12) for 1 hour starting at 2pm PDT.

An OS configuration issue needs to be resolved.

Dale

Dale Henrichs-3

SS3, Gemsource, book.pharo.project.org MAINTENANCE Tuesday June 25 from 12pm-4pm PDT

The 3 sites:

ss3.gemstone.com,
seaside.gemstone.com/ss
book.pharo-project.org

will be down for Maintenance on Tuesday, June 25, for 4 hours starting at 12pm PDT.

The servers are being relocated from a VMware data center to the GemTalk Systems data center.

I will send mail when the relocation is complete.

The ss3 and gemsource sites will have new domain names when they come back online:

ss3.gemstone.com -> ss3.gemtalksystems.com
seaside.gemstone.com -> seaside.gemtalksystems.com

The domain for book.pharo-project.org will not change.

All of the old domains will continue to be usable for about a year, but I recommend that you start switching to the new domain names as soon as you can.

WARNING: the new ss3.gemtalksystems.com and seaside.gemtalksystems.com sites may appear to be alive between now and 4pm PDT Tuesday, but be aware that anything saved on those sites prior to my "relocation complete email" may not be preserved.

Dale

Paul DeBruicker

Re: SS3, Gemsource, book.pharo.project.org MAINTENANCE Tuesday June 25 from 12pm-4pm PDT

Are you also upgrading SS3 during the move?

On 06/22/2013 06:59 AM, Dale K. Henrichs wrote:

> The 3 sites:
>
> ss3.gemstone.com,
> seaside.gemstone.com/ss
> book.pharo-project.org
>
> will be down for Maintenance on Tuesday, June 25, for 4 hours starting at 12pm PDT.
>
> The servers are being relocated from a VMware data center to the GemTalk Systems data center.
>
> I will send mail when the relocation is complete.
>
> The ss3 and gemsource sites will have new domain names when they come back online:
>
> ss3.gemstone.com -> ss3.gemtalksystems.com
> seaside.gemstone.com -> seaside.gemtalksystems.com
>
> The domain for book.pharo-project.org will not change.
>
> All of the old domains will continue to be usable for about a year, but I recommend that you start switching to the new domain names as soon as you can.
>
> WARNING: the new ss3.gemtalksystems.com and seaside.gemtalksystems.com sites may appear to be alive between now and 4pm PDT Tuesday, but be aware that anything saved on those sites prior to my "relocation complete email" may not be preserved.
>
> Dale
>

Dale Henrichs-3

Re: SS3, Gemsource, book.pharo.project.org MAINTENANCE Tuesday June 25 from 12pm-4pm PDT

Dale Henrichs-3

SS3, Gemsource, book.pharo.project.org MAINTENANCE has started

In reply to this post by Dale Henrichs-3

We have started maintenance on:

ss3.gemstone.com,
seaside.gemstone.com/ss
book.pharo-project.org

We expect the servers to be back online by 4pm PDT.

When the servers come back online you should start using the new domain names:

ss3.gemstone.com -> ss3.gemtalksystems.com
seaside.gemstone.com -> seaside.gemtalksystems.com

The domain for book.pharo-project.org will not change.

All of the old domains will continue to be usable for about a year, but I recommend that you start switching to the new domain names as soon as you can.

Dale

Dale Henrichs-3

SS3, Gemsource, book.pharo.project.org MAINTENANCE has completed

Maintenance is complete for the servers:

ss3.gemstone.com,
seaside.gemstone.com/ss
book.pharo-project.org

The machine that we're using to host the new site has more memory than the old VMware server, so I took the opportunity to increase the size of the Shared Page Cache to 4Gb and now the project searches and overall access is much snappier!

Please report any problems that you may encounter to me or admins at gemtalksystems dot com.

You should start using the new domain names:

ss3.gemstone.com -> ss3.gemtalksystems.com
seaside.gemstone.com -> seaside.gemtalksystems.com

The domain for book.pharo-project.org will not change.

All of the old domains will continue to be usable for about a year, but I recommend that you start switching to the new domain names as soon as you can.

Dale