Trying to upgrade from 2.4 to 3.1, maintenace gem problems

We are currently trying to upgrade from GemStone 2.4.4.1 to GemStone 3.1.0.1.

Ryan,

Nothing rings a bell so I think I'd like to see a sample of the Smalltalk stack from the maintenance vm ... use `kill -USR1 <pid>` a couple of times over several minutes so we can get an idea of what work is being done ...

I'm out of the office today, but tomorrow I'll check with some of the other guys at the office and see if this might be a known problem ...

Dale

---

From: "Ryan Simmons" <[hidden email]>
To: "GemStone Seaside beta discussion" <[hidden email]>
Sent: Monday, May 27, 2013 7:16:09 AM
Subject: [GS/SS Beta] Trying to upgrade from 2.4 to 3.1,        maintenace gem problems

We are currently trying to upgrade from GemStone 2.4.4.1 to GemStone 3.1.0.1.

The upgrade seems to work and we are able to access / use our seaside application. 

However the maintenance gem runs at about 15% io usage and produces about 1gb of tranlogs every hour even though the seaside application is not being accessed. This happens even if during the upgrade process I don't load in our code I only load in 

UserGlobals

  at: #BootstrapApplicationLoadSpecs

  put: {

      { 'ConfigurationOfGLASS'. '1.0-beta.8.7.2'. #('default'). BootstrapRepositoryDirectory. } .

      { 'ConfigurationOfSeaside30'.

        '3.0.7.1'. 

        #('default'). 

        '/home/xxxxxx/projects/gemstoneUpgrade'. 

      } }

I have attached a partial copy of printlogs.

Object 28733697 is a RcQueueSessionComponent that seems to be pretty large (21356 items)

Any ideas on where to proceed from here?

Regards

Ryan Simmons

Here is the stack

Ryan,

Sorry I haven't gotten back to you sooner ... You are hitting an error while processing a Mantenance VM task:

10  Object >> _uncontinuableError (envId 0) @IP 88  [GsNMethod 210694657]
              FP: 0x7f1d8257be28=StackLimit[-59] , callerFP: StackLimit[-55]
  rcvr: 0x7f1d9d39dab0 oid:186796289 (cls:84993 SimpleBlock size:9)
11  SimpleBlock >> value: (envId 0) @IP 72  [GsNMethod 213026561]
              FP: 0x7f1d8257be48=StackLimit[-55] , callerFP: StackLimit[-50]
  arg 1:0x7f1d9d39db10 oid:187936001 (cls:178872321 WAGemStoneMaintenanceTask size:5)
  rcvr: 0x7f1d9d39dab0 oid:186796289 (cls:84993 SimpleBlock size:9)
12  WAGemStoneMaintenanceTask >> performTask: (envId 0) @IP 144  [GsNMethod 3931217409]
              FP: 0x7f1d8257be70=StackLimit[-50] , callerFP: StackLimit[-44]
  arg 1:2 (SmallInteger 0)
  rcvr: 0x7f1d9d39db10 oid:187936001 (cls:178872321 WAGemStoneMaintenanceTask size:5)


It also looks like there is a commit being performed as part of an error handler in metaSystem(?):

1  SessionMethodTransactionBoundaryPolicy >> transactionBoundary: (envId 0) @IP 56  [GsNMethod 3935478273]
              FP: 0x7f1d8257bc78=StackLimit[-113] , callerFP: StackLimit[-107]
  arg 1:0x7f1d9d37f8b0 oid:6895361 (cls:110849 Symbol size:6)#commit
  rcvr: 0x7f1d9d382d20 oid:3935319809 (cls:16441089 SessionMethodTransactionBoundaryPolicy size:3)
2  TransactionBoundaryDefaultPolicy >> commit: (envId 0) @IP 112  [GsNMethod 957597441]
              FP: 0x7f1d8257bca8=StackLimit[-107] , callerFP: StackLimit[-101]
  arg 1:2 (SmallInteger 0)
  rcvr: 0x7f1d9d382d20 oid:3935319809 (cls:16441089 SessionMethodTransactionBoundaryPolicy size:3)
3   metaSystem >> _commit: (envId 0) @IP 128  [GsNMethod 212695041]
              FP: 0x7f1d8257bcd8=StackLimit[-101] , callerFP: StackLimit[-96]
  arg 1:2 (SmallInteger 0)
  rcvr: 0x7f1da65eb380 oid:76033 (cls:801793  metaSystem size:19)
4   metaSystem >> commitTransaction (envId 0) @IP 120  [GsNMethod 212717313]
              FP: 0x7f1d8257bd00=StackLimit[-96] , callerFP: StackLimit[-92]
  rcvr: 0x7f1da65eb380 oid:76033 (cls:801793  metaSystem size:19)
5  (block, homeMethod:6065165057) @IP 192  [GsNMethod 6065167873]
              FP: 0x7f1d8257bd20=StackLimit[-92] , callerFP: StackLimit[-84]
  arg 1:0x7f1d9002cab0 oid:6208356097 (cls:150529 UncontinuableError size:15)
  rcvr: 0x7f1d9d3801c8 oid:6065167361 (cls:128001 ExecBlock1 size:5)

So presumably once a minute this error is occuring and committing some data to the repository and thats leading to large tranlogs as well ...

When converting from 2.4 to 3.x, be aware that all methods and blocks need to be rebuilt ... loading in code again (done during a normal upgrade) covers most of the cases, but if you've got a block stashed somewhere it could be leading to the error ...

Also I notice that you are using 3.1.0.1. You should be using 3.1.0.2 as that is the current release ...

3.1.0.3 is "due to be released real soon" ... I know I've said that before and each time we have been a week or so away from release, but then someone finds a bug....

Dale

---

From: "Ryan Simmons" <[hidden email]>
To: "GemStone Seaside beta discussion" <[hidden email]>
Sent: Tuesday, May 28, 2013 10:50:26 AM
Subject: Re: [GS/SS Beta] Trying to upgrade from 2.4 to 3.1,        maintenace gem problems

Here is the stack

On 28 May 2013 01:20, Dale K. Henrichs <[hidden email]> wrote:

Ryan,

Nothing rings a bell so I think I'd like to see a sample of the Smalltalk stack from the maintenance vm ... use `kill -USR1 <pid>` a couple of times over several minutes so we can get an idea of what work is being done ...

I'm out of the office today, but tomorrow I'll check with some of the other guys at the office and see if this might be a known problem ...

Dale

---

From: "Ryan Simmons" <[hidden email]>
To: "GemStone Seaside beta discussion" <[hidden email]>
Sent: Monday, May 27, 2013 7:16:09 AM
Subject: [GS/SS Beta] Trying to upgrade from 2.4 to 3.1,        maintenace gem problems

We are currently trying to upgrade from GemStone 2.4.4.1 to GemStone 3.1.0.1.

The upgrade seems to work and we are able to access / use our seaside application. 

However the maintenance gem runs at about 15% io usage and produces about 1gb of tranlogs every hour even though the seaside application is not being accessed. This happens even if during the upgrade process I don't load in our code I only load in 

UserGlobals

  at: #BootstrapApplicationLoadSpecs

  put: {

      { 'ConfigurationOfGLASS'. '1.0-beta.8.7.2'. #('default'). BootstrapRepositoryDirectory. } .

      { 'ConfigurationOfSeaside30'.

        '3.0.7.1'. 

        #('default'). 

        '/home/xxxxxx/projects/gemstoneUpgrade'. 

      } }

I have attached a partial copy of printlogs.

Object 28733697 is a RcQueueSessionComponent that seems to be pretty large (21356 items)

Any ideas on where to proceed from here?

Regards

Ryan Simmons