Gembuilder tutorial documentation

--

GBS documentation is at http://community.gemstone.com/display/GSS64/GBS+Documentation. You can see other GemStone/S documentation links along the left.

Hello,
  I run a staging environment and a production environment. I make changes and experiment in staging, and bring over some of those changes into production. Eventually, production gets copied over to staging, and then the two systems diverge again.

  Now, when I go through the Patch Browser I am told that a lot of methods have "(source same but rev changed)". Is there any way to hide those methods? If the methods are identical, and they are, I don't want to see them in the list.

  Regards,

  Larry

Hello,
  Actually, I have far worse problems than just hiding changes in the Patch Browser. I just noticed that the log files for my Gems are spewing out this:




etryFailure
Read-Write Conflicts...
Write-Write Conflicts...
Write-Dependency Conflicts...
Write-ReadLock Conflicts...
Write-WriteLock Conflicts...
Rc-Write-Write Conflicts...
    440885505
Synchronized-Commit Conflicts...
----------- Commit failure - retrying LOG ENTRY: aSymbolDictionary-----------
-----------  Unreportable ERROR Encountered: 2012-07-08T18:37:39.67828106880188-07:00InterpreterError 2089: An index range was specified for a sequenceable collection with the starting index <1> greater than the ending index <0>.-----------
-----------  Unreportable ERROR Encountered: 2012-07-08T18:39:39.71508598327637-07:00InterpreterError 2089: An index range was specified for a sequenceable collection with the starting index <1> greater than the ending index <0>.-----------
-----------  Unreportable ERROR Encountered: 2012-07-08T18:41:39.78475308418274-07:00InterpreterError 2089: An index range was specified for a sequenceable collection with the starting index <1> greater than the ending index <0>.-----------
-----------  Unreportable ERROR Encountered: 2012-07-08T18:43:39.84294891357422-07:00InterpreterError 2089: An index range was specified for a sequenceable collection with the starting index <1> greater than the ending index <0>.-----------

on and on and on...

Help! What do I do? I took care of a walk back I add and actually have no idea what sequenceable collection is causing this problem.
My system is up and running fine but all of these errors are being thrown.


  Larry

Lawrence,

The only way to "suppress the source same but rev changed" is to reload (or revert) the mcz file and get the timestamps from the mcz file set correctly, once you do this you shouldn't have to do it over and over again ...

I have seen this every once in a while, but I haven't tracked the bug down (a revert seems to clean it up) ...

Do you happen to be using FileTree packages?

What kind of repositories are you using (Directory-based or Http) for the affect packages?

Dale


----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, July 9, 2012 4:31:23 PM
| Subject: [GS/SS Beta] Any way to hide (source same but rev changed) methods?
|
| Hello,
|   I run a staging environment and a production environment. I make
|   changes and experiment in staging, and bring over some of those
|   changes into production. Eventually, production gets copied over
|   to staging, and then the two systems diverge again.
|
|   Now, when I go through the Patch Browser I am told that a lot of
|   methods have "(source same but rev changed)". Is there any way to
|   hide those methods? If the methods are identical, and they are, I
|   don't want to see them in the list.
|
|   Regards,
|
|   Larry
|
|

Well let' see...

440885505 is the oop of the object that you are getting the Rc-Write-Write Conflicts on. You can use:

  Object _objectForOop: 440885505

to inspect the object ... the fact that it is an Rc error means that the type of conflict is one that is not resolvable by retry ... for an Rc Dictionary that means two sessions are using the adding/removing the same key ... For an Rc set that means two sessions are adding removing the same object ...

Inspect the object and find out ...


... I'll have more in a follow on mail...

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, July 9, 2012 4:42:13 PM
| Subject: [GS/SS Beta]  Far worse problems…
|
| Hello,
|   Actually, I have far worse problems than just hiding changes in the
|   Patch Browser. I just noticed that the log files for my Gems are
|   spewing out this:
|
|
|
|
| etryFailure
| Read-Write Conflicts...
| Write-Write Conflicts...
| Write-Dependency Conflicts...
| Write-ReadLock Conflicts...
| Write-WriteLock Conflicts...
| Rc-Write-Write Conflicts...
|     440885505
| Synchronized-Commit Conflicts...
| ----------- Commit failure - retrying LOG ENTRY:
| aSymbolDictionary-----------
| -----------  Unreportable ERROR Encountered:
| 2012-07-08T18:37:39.67828106880188-07:00InterpreterError 2089: An
| index range was specified for a sequenceable collection with the
| starting index <1> greater than the ending index <0>.-----------
| -----------  Unreportable ERROR Encountered:
| 2012-07-08T18:39:39.71508598327637-07:00InterpreterError 2089: An
| index range was specified for a sequenceable collection with the
| starting index <1> greater than the ending index <0>.-----------
| -----------  Unreportable ERROR Encountered:
| 2012-07-08T18:41:39.78475308418274-07:00InterpreterError 2089: An
| index range was specified for a sequenceable collection with the
| starting index <1> greater than the ending index <0>.-----------
| -----------  Unreportable ERROR Encountered:
| 2012-07-08T18:43:39.84294891357422-07:00InterpreterError 2089: An
| index range was specified for a sequenceable collection with the
| starting index <1> greater than the ending index <0>.-----------
|
| on and on and on...
|
| Help! What do I do? I took care of a walk back I add and actually
| have no idea what sequenceable collection is causing this problem.
| My system is up and running fine but all of these errors are being
| thrown.
|
|
|   Larry

Lawrence,

Whenever something like this happens, I always ask myself the question: "what did I just change" ... it's almost certain that the new behavior is the result of changes you made to the system ... Often a review of the changes combined with the error messages in the log (in the case commit conflicts) should point to the offending code ... alternatively you could could back out your code changes (reload the package versions from the previously know to work configuration) which should "fix the issues" ... then you can try to reproduce the problem in your sandbox and fix it there before reapplying the updates ...

To get more information about the "Unreportable ERROR" you can modify FSGsSocketServer>>notifyUnreportableError: (the likely source of the log entry) to look like this:

  notifyUnreportableError: aString
        "unconditional logging to stdout"
        | stdout stack |
        stack := GsProcess stackReportToLevel: 300.
        stdout := GsFile stdoutServer.
        stdout nextPutAll: '-----------  Unreportable ERROR Encountered: ', DateAndTime now printString.
        stdout nextPutAll: aString.
        stdout cr.
        stdout nextPutAll: stack.
        stdout nextPutAll: '-----------'.
        stdout cr.
        stdout close.

and get a stack dumped to the log...

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, July 9, 2012 4:42:13 PM
| Subject: [GS/SS Beta]  Far worse problems…
|
| Hello,
|   Actually, I have far worse problems than just hiding changes in the
|   Patch Browser. I just noticed that the log files for my Gems are
|   spewing out this:
|
|
|
|
| etryFailure
| Read-Write Conflicts...
| Write-Write Conflicts...
| Write-Dependency Conflicts...
| Write-ReadLock Conflicts...
| Write-WriteLock Conflicts...
| Rc-Write-Write Conflicts...
|     440885505
| Synchronized-Commit Conflicts...
| ----------- Commit failure - retrying LOG ENTRY:
| aSymbolDictionary-----------
| -----------  Unreportable ERROR Encountered:
| 2012-07-08T18:37:39.67828106880188-07:00InterpreterError 2089: An
| index range was specified for a sequenceable collection with the
| starting index <1> greater than the ending index <0>.-----------
| -----------  Unreportable ERROR Encountered:
| 2012-07-08T18:39:39.71508598327637-07:00InterpreterError 2089: An
| index range was specified for a sequenceable collection with the
| starting index <1> greater than the ending index <0>.-----------
| -----------  Unreportable ERROR Encountered:
| 2012-07-08T18:41:39.78475308418274-07:00InterpreterError 2089: An
| index range was specified for a sequenceable collection with the
| starting index <1> greater than the ending index <0>.-----------
| -----------  Unreportable ERROR Encountered:
| 2012-07-08T18:43:39.84294891357422-07:00InterpreterError 2089: An
| index range was specified for a sequenceable collection with the
| starting index <1> greater than the ending index <0>.-----------
|
| on and on and on...
|
| Help! What do I do? I took care of a walk back I add and actually
| have no idea what sequenceable collection is causing this problem.
| My system is up and running fine but all of these errors are being
| thrown.
|
|
|   Larry

The sessions are locked with object locks so you shouldn't be able to access the same session in two different servers.

The Document handler looks suspicious to me ... perhaps you have different sessions trying to add a document handler... this rings a bell but I can't recall the details .. it doesn't seem right that document handlers are being stored in the session dictionary ...

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, July 9, 2012 4:57:33 PM
| Subject: Re: [GS/SS Beta] Far worse problems…
|
|
|
|
| On Jul 9, 2012, at 7:51 PM, Dale Henrichs wrote:
|
|
|
| Well let' see...
|
| 440885505 is the oop of the object that you are getting the
| Rc-Write-Write Conflicts on. You can use:
|
| Object _objectForOop: 440885505
|
|
|
|
|
|
| Thanks, Dale.
|
|
| So, this object is a RcKeyValueDiction with two keys
|
|
| aWASession and a aWADocumentHandler.
|
|
| It does not seem like my code, but perhaps it has something to do
| with the session stuff.
| Out of all the code I wrote, I didn't expect this conflict. ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
| Any chance that this call to createCache in my session class is
| causing the problem?
|
|
|
| createCache
| "To configure the continuation cache you must currently subclass
| WASession and override this method."
| | policy |
| policy := WARcLastAccessExpiryPolicy new.
| policy configuration at: #cacheTimeout put: 3600.
| ^ WACache new
| setExpiryPolicy: policy;
| yourself.
|
|
| Larry
|
|
|
|
|
|
|
| to inspect the object ... the fact that it is an Rc error means that
| the type of conflict is one that is not resolvable by retry ... for
| an Rc Dictionary that means two sessions are using the
| adding/removing the same key ... For an Rc set that means two
| sessions are adding removing the same object ...
|
| Inspect the object and find out ...
|
|
| ... I'll have more in a follow on mail...
|
| Dale
|
| ----- Original Message -----
| | From: "Lawrence Kellogg" < [hidden email] >
| | To: "GemStone Seaside beta discussion" < [hidden email]
| | >
| | Sent: Monday, July 9, 2012 4:42:13 PM
| | Subject: [GS/SS Beta] Far worse problems…
| |
| | Hello,
| | Actually, I have far worse problems than just hiding changes in the
| | Patch Browser. I just noticed that the log files for my Gems are
| | spewing out this:
| |
| |
| |
| |
| | etryFailure
| | Read-Write Conflicts...
| | Write-Write Conflicts...
| | Write-Dependency Conflicts...
| | Write-ReadLock Conflicts...
| | Write-WriteLock Conflicts...
| | Rc-Write-Write Conflicts...
| | 440885505
| | Synchronized-Commit Conflicts...
| | ----------- Commit failure - retrying LOG ENTRY:
| | aSymbolDictionary-----------
| | ----------- Unreportable ERROR Encountered:
| | 2012-07-08T18:37:39.67828106880188-07:00InterpreterError 2089: An
| | index range was specified for a sequenceable collection with the
| | starting index <1> greater than the ending index <0>.-----------
| | ----------- Unreportable ERROR Encountered:
| | 2012-07-08T18:39:39.71508598327637-07:00InterpreterError 2089: An
| | index range was specified for a sequenceable collection with the
| | starting index <1> greater than the ending index <0>.-----------
| | ----------- Unreportable ERROR Encountered:
| | 2012-07-08T18:41:39.78475308418274-07:00InterpreterError 2089: An
| | index range was specified for a sequenceable collection with the
| | starting index <1> greater than the ending index <0>.-----------
| | ----------- Unreportable ERROR Encountered:
| | 2012-07-08T18:43:39.84294891357422-07:00InterpreterError 2089: An
| | index range was specified for a sequenceable collection with the
| | starting index <1> greater than the ending index <0>.-----------
| |
| | on and on and on...
| |
| | Help! What do I do? I took care of a walk back I add and actually
| | have no idea what sequenceable collection is causing this problem.
| | My system is up and running fine but all of these errors are being
| | thrown.
| |
| |
| | Larry
|
|

I don't think the expiry policy code would be related to this error unless you somehow have two maintenance vms running but in that case I'd expect the commit conflicts to be coming from the maintenance vms...

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, July 9, 2012 4:57:33 PM
| Subject: Re: [GS/SS Beta] Far worse problems…
|
|
|
|
| On Jul 9, 2012, at 7:51 PM, Dale Henrichs wrote:
|
|
|
| Well let' see...
|
| 440885505 is the oop of the object that you are getting the
| Rc-Write-Write Conflicts on. You can use:
|
| Object _objectForOop: 440885505
|
|
|
|
|
|
| Thanks, Dale.
|
|
| So, this object is a RcKeyValueDiction with two keys
|
|
| aWASession and a aWADocumentHandler.
|
|
| It does not seem like my code, but perhaps it has something to do
| with the session stuff.
| Out of all the code I wrote, I didn't expect this conflict. ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
| Any chance that this call to createCache in my session class is
| causing the problem?
|
|
|
| createCache
| "To configure the continuation cache you must currently subclass
| WASession and override this method."
| | policy |
| policy := WARcLastAccessExpiryPolicy new.
| policy configuration at: #cacheTimeout put: 3600.
| ^ WACache new
| setExpiryPolicy: policy;
| yourself.
|
|
| Larry
|
|
|
|
|
|
|
| to inspect the object ... the fact that it is an Rc error means that
| the type of conflict is one that is not resolvable by retry ... for
| an Rc Dictionary that means two sessions are using the
| adding/removing the same key ... For an Rc set that means two
| sessions are adding removing the same object ...
|
| Inspect the object and find out ...
|
|
| ... I'll have more in a follow on mail...
|
| Dale
|
| ----- Original Message -----
| | From: "Lawrence Kellogg" < [hidden email] >
| | To: "GemStone Seaside beta discussion" < [hidden email]
| | >
| | Sent: Monday, July 9, 2012 4:42:13 PM
| | Subject: [GS/SS Beta] Far worse problems…
| |
| | Hello,
| | Actually, I have far worse problems than just hiding changes in the
| | Patch Browser. I just noticed that the log files for my Gems are
| | spewing out this:
| |
| |
| |
| |
| | etryFailure
| | Read-Write Conflicts...
| | Write-Write Conflicts...
| | Write-Dependency Conflicts...
| | Write-ReadLock Conflicts...
| | Write-WriteLock Conflicts...
| | Rc-Write-Write Conflicts...
| | 440885505
| | Synchronized-Commit Conflicts...
| | ----------- Commit failure - retrying LOG ENTRY:
| | aSymbolDictionary-----------
| | ----------- Unreportable ERROR Encountered:
| | 2012-07-08T18:37:39.67828106880188-07:00InterpreterError 2089: An
| | index range was specified for a sequenceable collection with the
| | starting index <1> greater than the ending index <0>.-----------
| | ----------- Unreportable ERROR Encountered:
| | 2012-07-08T18:39:39.71508598327637-07:00InterpreterError 2089: An
| | index range was specified for a sequenceable collection with the
| | starting index <1> greater than the ending index <0>.-----------
| | ----------- Unreportable ERROR Encountered:
| | 2012-07-08T18:41:39.78475308418274-07:00InterpreterError 2089: An
| | index range was specified for a sequenceable collection with the
| | starting index <1> greater than the ending index <0>.-----------
| | ----------- Unreportable ERROR Encountered:
| | 2012-07-08T18:43:39.84294891357422-07:00InterpreterError 2089: An
| | index range was specified for a sequenceable collection with the
| | starting index <1> greater than the ending index <0>.-----------
| |
| | on and on and on...
| |
| | Help! What do I do? I took care of a walk back I add and actually
| | have no idea what sequenceable collection is causing this problem.
| | My system is up and running fine but all of these errors are being
| | thrown.
| |
| |
| | Larry
|
|

Thanks for the code snippet. Well, here is the stack. I'm mystified by it.


1> greater than the ending index <0>.-----------
-----------  Unreportable ERROR Encountered: 2012-07-09T17:05:53.9349250793457-07:00InterpreterError 2089: An index range was specified for a sequenceable collection with the starting index <1> greater than the ending index <0>.
1 FSGsSocketServer >> notifyUnreportableError: @2 line 4  [GsMethod OOP 472284673]
2 ComplexBlock in FSConnection >> notifyUnreportableError: @4 line 6  [GsMethod OOP 219648257]
3 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
4 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
5 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
6 FSConnection >> notifyUnreportableError: @6 line 7  [GsMethod OOP 219648257]
7 ComplexBlock in FSConnection >> handleError: @28 line 23  [GsMethod OOP 499287553]
8 ExceptionHandler >> caughtExceptionWithAction: @5 line 4  [GsMethod OOP 10065153]
9 ComplexBlock in ExceptionHandler >> caughtEx:number:cat:args:handler: @12 line 13  [GsMethod OOP 10064641]
10 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
11 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
12 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14  [GsMethod OOP 10064641]
13 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12  [GsMethod OOP 10062081]
14 Exception >> _signal:number:args: @2 line 7  [GsMethod OOP 2327041]
15 ExceptionA >> signal @14 line 41  [GsMethod OOP 10057473]
16 GsError >> signal @3 line 5  [GsMethod OOP 20972033]
17 ExceptionA >> signal: @3 line 12  [GsMethod OOP 10050817]
18 ExceptionA class >> signal: @2 line 3  [GsMethod OOP 11895041]
19 GsError class >> signal: @3 line 5  [GsMethod OOP 21805313]
20 UserDefinedError class >> signal: @3 line 4  [GsMethod OOP 22234625]
21 Object >> error: @3 line 7  [GsMethod OOP 19075073]
22 FSGsSocket >> nextPutAll: @10 line 6  [GsMethod OOP 219493633]
23 FSRecordStruct >> writeToStream: @14 line 14  [GsMethod OOP 219521281]
24 ComplexBlock in FSRecordSeries >> writeToStream: @7 line 3  [GsMethod OOP 218670849]
25 Collection >> do: @5 line 10  [GsMethod OOP 1547777]
26 FSRecordSeries >> writeToStream: @8 line 3  [GsMethod OOP 218670849]
27 FSConnection >> writeRecord: @6 line 3  [GsMethod OOP 219649793]
28 ComplexVCBlock in FSConnection >> handleError: @25 line 21  [GsMethod OOP 499287553]
29 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
30 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
31 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
32 FSConnection >> handleError: @29 line 22  [GsMethod OOP 499287553]
33 ComplexBlock in FSConnection >> safeServe @10 line 13  [GsMethod OOP 499288833]
34 ExceptionHandler >> caughtExceptionWithAction: @5 line 4  [GsMethod OOP 10065153]
35 ComplexBlock in ExceptionHandler >> caughtEx:number:cat:args:handler: @12 line 13  [GsMethod OOP 10064641]
36 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
37 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
38 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14  [GsMethod OOP 10064641]
39 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12  [GsMethod OOP 10062081]
40 Exception >> _signal:number:args: @2 line 7  [GsMethod OOP 2327041]
41 System class >> signal:args:signalDictionary: @5 line 13  [GsMethod OOP 3241473]
42 Object >> _error:args: @7 line 10  [GsMethod OOP 1926401]
43 SequenceableCollection >> copyFrom:to:into:startingAt: @4 line 14  [GsMethod OOP 3408129]
44 ByteArray >> copyFrom:to:into:startingAt: @3 line 11  [GsMethod OOP 7201025]
45 FSGsSocket >> next: @37 line 30  [GsMethod OOP 219493889]
46 FSGsSocket >> next @2 line 5  [GsMethod OOP 219491841]
47 FSRecordStruct >> readFromStream: @2 line 5  [GsMethod OOP 219522305]
48 FSRecordStruct class >> readFromStream: @2 line 2  [GsMethod OOP 219465473]
49 FSGsSocket >> nextRecordStruct @2 line 6  [GsMethod OOP 499268097]
50 FSConnection >> nextAppRecordStruct @2 line 6  [GsMethod OOP 219650305]
51 FSConnection >> nextAppRecord @1 line 7  [GsMethod OOP 219650561]
52 FSConnection >> makeActive @2 line 6  [GsMethod OOP 499286785]
53 FSConnection >> unsafeServe @3 line 7  [GsMethod OOP 219646465]
54 ComplexBlock in FSConnection >> safeServe @5 line 8  [GsMethod OOP 499288833]
55 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
56 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
57 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
58 ComplexVCBlock in FSConnection >> safeServe @8 line 9  [GsMethod OOP 499288833]
59 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
60 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
61 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
62 ComplexVCBlock in FSConnection >> safeServe @11 line 12  [GsMethod OOP 499288833]
63 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
64 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
65 FSConnection >> safeServe @14 line 15  [GsMethod OOP 499288833]
66 FSConnection >> serve @1 line 4  [GsMethod OOP 219654145]
67 ComplexBlock in FSSocketServer >> listen: @9 line 15  [GsMethod OOP 219292673]
68 GsProcess >> _startPart2 @15 line 17  [GsMethod OOP 4501249]
69 GsProcess >> _start @1 line 9  [GsMethod OOP 4501761]
On Jul 9, 2012, at 8:02 PM, Dale Henrichs wrote:

Two document handlers with the same document will compare #= so two different sessions creating document handlers with the same document will conflict ...

it would be interesting to see the document contents of the WADocument...that might have meaning for you..

Dale


----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, July 9, 2012 5:05:18 PM
| Subject: Re: [GS/SS Beta] Far worse problems…
|
| The sessions are locked with object locks so you shouldn't be able to
| access the same session in two different servers.
|
| The Document handler looks suspicious to me ... perhaps you have
| different sessions trying to add a document handler... this rings a
| bell but I can't recall the details .. it doesn't seem right that
| document handlers are being stored in the session dictionary ...
|
| Dale
|
| ----- Original Message -----
| | From: "Lawrence Kellogg" <[hidden email]>
| | To: "GemStone Seaside beta discussion" <[hidden email]>
| | Sent: Monday, July 9, 2012 4:57:33 PM
| | Subject: Re: [GS/SS Beta] Far worse problems…
| |
| |
| |
| |
| | On Jul 9, 2012, at 7:51 PM, Dale Henrichs wrote:
| |
| |
| |
| | Well let' see...
| |
| | 440885505 is the oop of the object that you are getting the
| | Rc-Write-Write Conflicts on. You can use:
| |
| | Object _objectForOop: 440885505
| |
| |
| |
| |
| |
| |
| | Thanks, Dale.
| |
| |
| | So, this object is a RcKeyValueDiction with two keys
| |
| |
| | aWASession and a aWADocumentHandler.
| |
| |
| | It does not seem like my code, but perhaps it has something to do
| | with the session stuff.
| | Out of all the code I wrote, I didn't expect this conflict. ;-)
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | Any chance that this call to createCache in my session class is
| | causing the problem?
| |
| |
| |
| | createCache
| | "To configure the continuation cache you must currently subclass
| | WASession and override this method."
| | | policy |
| | policy := WARcLastAccessExpiryPolicy new.
| | policy configuration at: #cacheTimeout put: 3600.
| | ^ WACache new
| | setExpiryPolicy: policy;
| | yourself.
| |
| |
| | Larry
| |
| |
| |
| |
| |
| |
| |
| | to inspect the object ... the fact that it is an Rc error means
| | that
| | the type of conflict is one that is not resolvable by retry ... for
| | an Rc Dictionary that means two sessions are using the
| | adding/removing the same key ... For an Rc set that means two
| | sessions are adding removing the same object ...
| |
| | Inspect the object and find out ...
| |
| |
| | ... I'll have more in a follow on mail...
| |
| | Dale
| |
| | ----- Original Message -----
| | | From: "Lawrence Kellogg" < [hidden email] >
| | | To: "GemStone Seaside beta discussion" <
| | | [hidden email]
| | | >
| | | Sent: Monday, July 9, 2012 4:42:13 PM
| | | Subject: [GS/SS Beta] Far worse problems…
| | |
| | | Hello,
| | | Actually, I have far worse problems than just hiding changes in
| | | the
| | | Patch Browser. I just noticed that the log files for my Gems are
| | | spewing out this:
| | |
| | |
| | |
| | |
| | | etryFailure
| | | Read-Write Conflicts...
| | | Write-Write Conflicts...
| | | Write-Dependency Conflicts...
| | | Write-ReadLock Conflicts...
| | | Write-WriteLock Conflicts...
| | | Rc-Write-Write Conflicts...
| | | 440885505
| | | Synchronized-Commit Conflicts...
| | | ----------- Commit failure - retrying LOG ENTRY:
| | | aSymbolDictionary-----------
| | | ----------- Unreportable ERROR Encountered:
| | | 2012-07-08T18:37:39.67828106880188-07:00InterpreterError 2089: An
| | | index range was specified for a sequenceable collection with the
| | | starting index <1> greater than the ending index <0>.-----------
| | | ----------- Unreportable ERROR Encountered:
| | | 2012-07-08T18:39:39.71508598327637-07:00InterpreterError 2089: An
| | | index range was specified for a sequenceable collection with the
| | | starting index <1> greater than the ending index <0>.-----------
| | | ----------- Unreportable ERROR Encountered:
| | | 2012-07-08T18:41:39.78475308418274-07:00InterpreterError 2089: An
| | | index range was specified for a sequenceable collection with the
| | | starting index <1> greater than the ending index <0>.-----------
| | | ----------- Unreportable ERROR Encountered:
| | | 2012-07-08T18:43:39.84294891357422-07:00InterpreterError 2089: An
| | | index range was specified for a sequenceable collection with the
| | | starting index <1> greater than the ending index <0>.-----------
| | |
| | | on and on and on...
| | |
| | | Help! What do I do? I took care of a walk back I add and actually
| | | have no idea what sequenceable collection is causing this
| | | problem.
| | | My system is up and running fine but all of these errors are
| | | being
| | | thrown.
| | |
| | |
| | | Larry
| |
| |
|

On Jul 9, 2012, at 8:08 PM, Dale Henrichs wrote:

> I don't think the expiry policy code would be related to this error unless you somehow have two maintenance vms running but in that case I'd expect the commit conflicts to be coming from the maintenance vas…


  I think you're right. I took out the code but it doesn't make any difference, I still get the exception.

  Larry

On Jul 9, 2012, at 8:12 PM, Dale Henrichs wrote:

> Two document handlers with the same document will compare #= so two different sessions creating document handlers with the same document will conflict ...
>
> it would be interesting to see the document contents of the WADocument...that might have meaning for you..
>

Well, that OOP now points a an empty dictionary. I tried to look at the contents of the WADocument but it was a garage string, as far as I could tell.

  You know, it only mentions the Rc-Write-Write conflict once and then it spews out hundreds of Unreportable errors. Now, I think it is still generating those errors, with a stack dump, but I can't figure out anything from the stack dump as to what is going wrong.

  Larry

The interesting part of the stack is:
...
42 Object >> _error:args: @7 line 10  [GsMethod OOP 1926401]
43 SequenceableCollection >> copyFrom:to:into:startingAt: @4 line 14  [GsMethod OOP 3408129]
44 ByteArray >> copyFrom:to:into:startingAt: @3 line 11  [GsMethod OOP 7201025]
45 FSGsSocket >> next: @37 line 30  [GsMethod OOP 219493889]
46 FSGsSocket >> next @2 line 5  [GsMethod OOP 219491841]
47 FSRecordStruct >> readFromStream: @2 line 5  [GsMethod OOP 219522305]
48 FSRecordStruct class >> readFromStream: @2 line 2  [GsMethod OOP 219465473]
49 FSGsSocket >> nextRecordStruct @2 line 6  [GsMethod OOP 499268097]
50 FSConnection >> nextAppRecordStruct @2 line 6  [GsMethod OOP 219650305]
51 FSConnection >> nextAppRecord @1 line 7  [GsMethod OOP 219650561]
52 FSConnection >> makeActive @2 line 6  [GsMethod OOP 499286785]
...


Without more information, I'd guess the that the "Unreportable ERROR" are coming someone is hitting your server vms with invalid FASTCgi packets ... presumably you have correctly formed packets coming in because the web-site is being served correctly , but the fact that FastCGI is getting a error while reading records ... #makeActive is interpretting the incoming bytes...

So there are two different errors involved:

  the commit conflict coming from valid fastcgi packets
  the "Unreportable ERROR" coming from presumably invalid fastcgi packets

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, July 9, 2012 5:10:30 PM
| Subject: Re: [GS/SS Beta] Far worse problems…
|
| Thanks for the code snippet. Well, here is the stack. I'm mystified
| by it.
|
|
| 1> greater than the ending index <0>.-----------
| -----------  Unreportable ERROR Encountered:
| 2012-07-09T17:05:53.9349250793457-07:00InterpreterError 2089: An
| index range was specified for a sequenceable collection with the
| starting index <1> greater than the ending index <0>.
| 1 FSGsSocketServer >> notifyUnreportableError: @2 line 4  [GsMethod
| OOP 472284673]
| 2 ComplexBlock in FSConnection >> notifyUnreportableError: @4 line 6
|  [GsMethod OOP 219648257]
| 3 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
| 4 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
| 5 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP
| 9005057]
| 6 FSConnection >> notifyUnreportableError: @6 line 7  [GsMethod OOP
| 219648257]
| 7 ComplexBlock in FSConnection >> handleError: @28 line 23  [GsMethod
| OOP 499287553]
| 8 ExceptionHandler >> caughtExceptionWithAction: @5 line 4  [GsMethod
| OOP 10065153]
| 9 ComplexBlock in ExceptionHandler >>
| caughtEx:number:cat:args:handler: @12 line 13  [GsMethod OOP
| 10064641]
| 10 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod
| OOP 2304001]
| 11 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod
| OOP 2304001]
| 12 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14
|  [GsMethod OOP 10064641]
| 13 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12
|  [GsMethod OOP 10062081]
| 14 Exception >> _signal:number:args: @2 line 7  [GsMethod OOP
| 2327041]
| 15 ExceptionA >> signal @14 line 41  [GsMethod OOP 10057473]
| 16 GsError >> signal @3 line 5  [GsMethod OOP 20972033]
| 17 ExceptionA >> signal: @3 line 12  [GsMethod OOP 10050817]
| 18 ExceptionA class >> signal: @2 line 3  [GsMethod OOP 11895041]
| 19 GsError class >> signal: @3 line 5  [GsMethod OOP 21805313]
| 20 UserDefinedError class >> signal: @3 line 4  [GsMethod OOP
| 22234625]
| 21 Object >> error: @3 line 7  [GsMethod OOP 19075073]
| 22 FSGsSocket >> nextPutAll: @10 line 6  [GsMethod OOP 219493633]
| 23 FSRecordStruct >> writeToStream: @14 line 14  [GsMethod OOP
| 219521281]
| 24 ComplexBlock in FSRecordSeries >> writeToStream: @7 line 3
|  [GsMethod OOP 218670849]
| 25 Collection >> do: @5 line 10  [GsMethod OOP 1547777]
| 26 FSRecordSeries >> writeToStream: @8 line 3  [GsMethod OOP
| 218670849]
| 27 FSConnection >> writeRecord: @6 line 3  [GsMethod OOP 219649793]
| 28 ComplexVCBlock in FSConnection >> handleError: @25 line 21
|  [GsMethod OOP 499287553]
| 29 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
| 30 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| 10062081]
| 31 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod
| OOP 9005057]
| 32 FSConnection >> handleError: @29 line 22  [GsMethod OOP 499287553]
| 33 ComplexBlock in FSConnection >> safeServe @10 line 13  [GsMethod
| OOP 499288833]
| 34 ExceptionHandler >> caughtExceptionWithAction: @5 line 4
|  [GsMethod OOP 10065153]
| 35 ComplexBlock in ExceptionHandler >>
| caughtEx:number:cat:args:handler: @12 line 13  [GsMethod OOP
| 10064641]
| 36 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod
| OOP 2304001]
| 37 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod
| OOP 2304001]
| 38 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14
|  [GsMethod OOP 10064641]
| 39 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12
|  [GsMethod OOP 10062081]
| 40 Exception >> _signal:number:args: @2 line 7  [GsMethod OOP
| 2327041]
| 41 System class >> signal:args:signalDictionary: @5 line 13
|  [GsMethod OOP 3241473]
| 42 Object >> _error:args: @7 line 10  [GsMethod OOP 1926401]
| 43 SequenceableCollection >> copyFrom:to:into:startingAt: @4 line 14
|  [GsMethod OOP 3408129]
| 44 ByteArray >> copyFrom:to:into:startingAt: @3 line 11  [GsMethod
| OOP 7201025]
| 45 FSGsSocket >> next: @37 line 30  [GsMethod OOP 219493889]
| 46 FSGsSocket >> next @2 line 5  [GsMethod OOP 219491841]
| 47 FSRecordStruct >> readFromStream: @2 line 5  [GsMethod OOP
| 219522305]
| 48 FSRecordStruct class >> readFromStream: @2 line 2  [GsMethod OOP
| 219465473]
| 49 FSGsSocket >> nextRecordStruct @2 line 6  [GsMethod OOP 499268097]
| 50 FSConnection >> nextAppRecordStruct @2 line 6  [GsMethod OOP
| 219650305]
| 51 FSConnection >> nextAppRecord @1 line 7  [GsMethod OOP 219650561]
| 52 FSConnection >> makeActive @2 line 6  [GsMethod OOP 499286785]
| 53 FSConnection >> unsafeServe @3 line 7  [GsMethod OOP 219646465]
| 54 ComplexBlock in FSConnection >> safeServe @5 line 8  [GsMethod OOP
| 499288833]
| 55 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
| 56 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| 10062081]
| 57 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP
| 9005057]
| 58 ComplexVCBlock in FSConnection >> safeServe @8 line 9  [GsMethod
| OOP 499288833]
| 59 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
| 60 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| 10062081]
| 61 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod
| OOP 9005057]
| 62 ComplexVCBlock in FSConnection >> safeServe @11 line 12  [GsMethod
| OOP 499288833]
| 63 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod
| OOP 2304001]
| 64 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod
| OOP 2304001]
| 65 FSConnection >> safeServe @14 line 15  [GsMethod OOP 499288833]
| 66 FSConnection >> serve @1 line 4  [GsMethod OOP 219654145]
| 67 ComplexBlock in FSSocketServer >> listen: @9 line 15  [GsMethod
| OOP 219292673]
| 68 GsProcess >> _startPart2 @15 line 17  [GsMethod OOP 4501249]
| 69 GsProcess >> _start @1 line 9  [GsMethod OOP 4501761]
| On Jul 9, 2012, at 8:02 PM, Dale Henrichs wrote:
|
| > Lawrence,
| >
| > Whenever something like this happens, I always ask myself the
| > question: "what did I just change" ... it's almost certain that
| > the new behavior is the result of changes you made to the system
| > ... Often a review of the changes combined with the error messages
| > in the log (in the case commit conflicts) should point to the
| > offending code ... alternatively you could could back out your
| > code changes (reload the package versions from the previously know
| > to work configuration) which should "fix the issues" ... then you
| > can try to reproduce the problem in your sandbox and fix it there
| > before reapplying the updates ...
| >
| > To get more information about the "Unreportable ERROR" you can
| > modify FSGsSocketServer>>notifyUnreportableError: (the likely
| > source of the log entry) to look like this:
| >
| >  notifyUnreportableError: aString
| > "unconditional logging to stdout"
| > | stdout stack |
| > stack := GsProcess stackReportToLevel: 300.
| > stdout := GsFile stdoutServer.
| > stdout nextPutAll: '-----------  Unreportable ERROR Encountered:
| > ', DateAndTime now printString.
| > stdout nextPutAll: aString.
| > stdout cr.
| > stdout nextPutAll: stack.
| > stdout nextPutAll: '-----------'.
| > stdout cr.
| > stdout close.
| >
| > and get a stack dumped to the log...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Lawrence Kellogg" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Monday, July 9, 2012 4:42:13 PM
| > | Subject: [GS/SS Beta]  Far worse problems…
| > |
| > | Hello,
| > |   Actually, I have far worse problems than just hiding changes in
| > |   the
| > |   Patch Browser. I just noticed that the log files for my Gems
| > |   are
| > |   spewing out this:
| > |
| > |
| > |
| > |
| > | etryFailure
| > | Read-Write Conflicts...
| > | Write-Write Conflicts...
| > | Write-Dependency Conflicts...
| > | Write-ReadLock Conflicts...
| > | Write-WriteLock Conflicts...
| > | Rc-Write-Write Conflicts...
| > |     440885505
| > | Synchronized-Commit Conflicts...
| > | ----------- Commit failure - retrying LOG ENTRY:
| > | aSymbolDictionary-----------
| > | -----------  Unreportable ERROR Encountered:
| > | 2012-07-08T18:37:39.67828106880188-07:00InterpreterError 2089: An
| > | index range was specified for a sequenceable collection with the
| > | starting index <1> greater than the ending index <0>.-----------
| > | -----------  Unreportable ERROR Encountered:
| > | 2012-07-08T18:39:39.71508598327637-07:00InterpreterError 2089: An
| > | index range was specified for a sequenceable collection with the
| > | starting index <1> greater than the ending index <0>.-----------
| > | -----------  Unreportable ERROR Encountered:
| > | 2012-07-08T18:41:39.78475308418274-07:00InterpreterError 2089: An
| > | index range was specified for a sequenceable collection with the
| > | starting index <1> greater than the ending index <0>.-----------
| > | -----------  Unreportable ERROR Encountered:
| > | 2012-07-08T18:43:39.84294891357422-07:00InterpreterError 2089: An
| > | index range was specified for a sequenceable collection with the
| > | starting index <1> greater than the ending index <0>.-----------
| > |
| > | on and on and on...
| > |
| > | Help! What do I do? I took care of a walk back I add and actually
| > | have no idea what sequenceable collection is causing this
| > | problem.
| > | My system is up and running fine but all of these errors are
| > | being
| > | thrown.
| > |
| > |
| > |   Larry
|
|

On Jul 9, 2012, at 8:22 PM, Dale Henrichs wrote:

  Interesting. How in the world am I being hit with invalid fastcgi traffic? Am I under attack?
Yes, the website is up and serving traffic correctly.

  Funny that the Rc-Write-Write error is somehow related to session and document handlers….

  Larry

Is there a timestamp on the commit conflict log entry?

Occasional commit conflicts are not actually cause for alarm ... according the log, the commit conflict was retried ... without further errors about the the retry limit being exceeded I'm pretty sure that the retry succeeded ...

The "Unreportable ERROR" is very liklye coming from some process (most likely on your box) trying to connect to the fastCGI ports without actually passing in valid fastCGI ...

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, July 9, 2012 5:22:14 PM
| Subject: Re: [GS/SS Beta] Far worse problems…
|
|
| On Jul 9, 2012, at 8:12 PM, Dale Henrichs wrote:
|
| > Two document handlers with the same document will compare #= so two
| > different sessions creating document handlers with the same
| > document will conflict ...
| >
| > it would be interesting to see the document contents of the
| > WADocument...that might have meaning for you..
| >
|
| Well, that OOP now points a an empty dictionary. I tried to look at
| the contents of the WADocument but it was a garage string, as far as
| I could tell.
|
|   You know, it only mentions the Rc-Write-Write conflict once and
|   then it spews out hundreds of Unreportable errors. Now, I think it
|   is still generating those errors, with a stack dump, but I can't
|   figure out anything from the stack dump as to what is going wrong.
|
|   Larry
|
|
|
|
| > Dale
| >
| >
| > ----- Original Message -----
| > | From: "Dale Henrichs" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Monday, July 9, 2012 5:05:18 PM
| > | Subject: Re: [GS/SS Beta] Far worse problems…
| > |
| > | The sessions are locked with object locks so you shouldn't be
| > | able to
| > | access the same session in two different servers.
| > |
| > | The Document handler looks suspicious to me ... perhaps you have
| > | different sessions trying to add a document handler... this rings
| > | a
| > | bell but I can't recall the details .. it doesn't seem right that
| > | document handlers are being stored in the session dictionary ...
| > |
| > | Dale
| > |
| > | ----- Original Message -----
| > | | From: "Lawrence Kellogg" <[hidden email]>
| > | | To: "GemStone Seaside beta discussion"
| > | | <[hidden email]>
| > | | Sent: Monday, July 9, 2012 4:57:33 PM
| > | | Subject: Re: [GS/SS Beta] Far worse problems…
| > | |
| > | |
| > | |
| > | |
| > | | On Jul 9, 2012, at 7:51 PM, Dale Henrichs wrote:
| > | |
| > | |
| > | |
| > | | Well let' see...
| > | |
| > | | 440885505 is the oop of the object that you are getting the
| > | | Rc-Write-Write Conflicts on. You can use:
| > | |
| > | | Object _objectForOop: 440885505
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | | Thanks, Dale.
| > | |
| > | |
| > | | So, this object is a RcKeyValueDiction with two keys
| > | |
| > | |
| > | | aWASession and a aWADocumentHandler.
| > | |
| > | |
| > | | It does not seem like my code, but perhaps it has something to
| > | | do
| > | | with the session stuff.
| > | | Out of all the code I wrote, I didn't expect this conflict. ;-)
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | | Any chance that this call to createCache in my session class is
| > | | causing the problem?
| > | |
| > | |
| > | |
| > | | createCache
| > | | "To configure the continuation cache you must currently
| > | | subclass
| > | | WASession and override this method."
| > | | | policy |
| > | | policy := WARcLastAccessExpiryPolicy new.
| > | | policy configuration at: #cacheTimeout put: 3600.
| > | | ^ WACache new
| > | | setExpiryPolicy: policy;
| > | | yourself.
| > | |
| > | |
| > | | Larry
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | |
| > | | to inspect the object ... the fact that it is an Rc error means
| > | | that
| > | | the type of conflict is one that is not resolvable by retry ...
| > | | for
| > | | an Rc Dictionary that means two sessions are using the
| > | | adding/removing the same key ... For an Rc set that means two
| > | | sessions are adding removing the same object ...
| > | |
| > | | Inspect the object and find out ...
| > | |
| > | |
| > | | ... I'll have more in a follow on mail...
| > | |
| > | | Dale
| > | |
| > | | ----- Original Message -----
| > | | | From: "Lawrence Kellogg" < [hidden email] >
| > | | | To: "GemStone Seaside beta discussion" <
| > | | | [hidden email]
| > | | | >
| > | | | Sent: Monday, July 9, 2012 4:42:13 PM
| > | | | Subject: [GS/SS Beta] Far worse problems…
| > | | |
| > | | | Hello,
| > | | | Actually, I have far worse problems than just hiding changes
| > | | | in
| > | | | the
| > | | | Patch Browser. I just noticed that the log files for my Gems
| > | | | are
| > | | | spewing out this:
| > | | |
| > | | |
| > | | |
| > | | |
| > | | | etryFailure
| > | | | Read-Write Conflicts...
| > | | | Write-Write Conflicts...
| > | | | Write-Dependency Conflicts...
| > | | | Write-ReadLock Conflicts...
| > | | | Write-WriteLock Conflicts...
| > | | | Rc-Write-Write Conflicts...
| > | | | 440885505
| > | | | Synchronized-Commit Conflicts...
| > | | | ----------- Commit failure - retrying LOG ENTRY:
| > | | | aSymbolDictionary-----------
| > | | | ----------- Unreportable ERROR Encountered:
| > | | | 2012-07-08T18:37:39.67828106880188-07:00InterpreterError
| > | | | 2089: An
| > | | | index range was specified for a sequenceable collection with
| > | | | the
| > | | | starting index <1> greater than the ending index
| > | | | <0>.-----------
| > | | | ----------- Unreportable ERROR Encountered:
| > | | | 2012-07-08T18:39:39.71508598327637-07:00InterpreterError
| > | | | 2089: An
| > | | | index range was specified for a sequenceable collection with
| > | | | the
| > | | | starting index <1> greater than the ending index
| > | | | <0>.-----------
| > | | | ----------- Unreportable ERROR Encountered:
| > | | | 2012-07-08T18:41:39.78475308418274-07:00InterpreterError
| > | | | 2089: An
| > | | | index range was specified for a sequenceable collection with
| > | | | the
| > | | | starting index <1> greater than the ending index
| > | | | <0>.-----------
| > | | | ----------- Unreportable ERROR Encountered:
| > | | | 2012-07-08T18:43:39.84294891357422-07:00InterpreterError
| > | | | 2089: An
| > | | | index range was specified for a sequenceable collection with
| > | | | the
| > | | | starting index <1> greater than the ending index
| > | | | <0>.-----------
| > | | |
| > | | | on and on and on...
| > | | |
| > | | | Help! What do I do? I took care of a walk back I add and
| > | | | actually
| > | | | have no idea what sequenceable collection is causing this
| > | | | problem.
| > | | | My system is up and running fine but all of these errors are
| > | | | being
| > | | | thrown.
| > | | |
| > | | |
| > | | | Larry
| > | |
| > | |
| > |
|
|

On Jul 9, 2012, at 8:26 PM, Dale Henrichs wrote:

> Is there a timestamp on the commit conflict log entry?
>

No timestamp on the commit conflict, just from the unrepeatable errors around it….


-----------  Unreportable ERROR Encountered: 2012-07-08T06:20:56.84343409538269-07:00InterpreterError 2089: An index range was specified for a sequenceable collection with the starting index <1> greater than the ending index <0>.-----------
retryFailure
Read-Write Conflicts...
Write-Write Conflicts...
Write-Dependency Conflicts...
Write-ReadLock Conflicts...
Write-WriteLock Conflicts...
Rc-Write-Write Conflicts...
    440885505
Synchronized-Commit Conflicts...
----------- Commit failure - retrying LOG ENTRY: aSymbolDictionary-----------
-----------  Unreportable ERROR Encountered: 2012-07-08T06:22:56.88573288917542-07:00InterpreterError 2089: An index range was specified for a sequenceable collection with the starting index <1> greater than the ending index <0>.--





> Occasional commit conflicts are not actually cause for alarm ... according the log, the commit conflict was retried ... without further errors about the the retry limit being exceeded I'm pretty sure that the retry succeeded ...
>
> The "Unreportable ERROR" is very liklye coming from some process (most likely on your box) trying to connect to the fastCGI ports without actually passing in valid fastCGI …
>

I'll have to think about this…. not sure what it could be at the moment...

  Larry

I don't think you are under attack from the outside  ... unless you changed some settings on your web server and are forwarding http traffic directly to your seaside servers (instead of fastCGI traffic) ...

Since it appears that a zero length collection involved, I would guess that you have a process on your box (telnet, or a monitoring daemon) connecting to the port that your seaside server is listening on and then disconnecting

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, July 9, 2012 5:26:56 PM
| Subject: Re: [GS/SS Beta] Far worse problems…
|
|
| On Jul 9, 2012, at 8:22 PM, Dale Henrichs wrote:
|
| > The interesting part of the stack is:
| > ...
| > 42 Object >> _error:args: @7 line 10  [GsMethod OOP 1926401]
| > 43 SequenceableCollection >> copyFrom:to:into:startingAt: @4 line
| > 14  [GsMethod OOP 3408129]
| > 44 ByteArray >> copyFrom:to:into:startingAt: @3 line 11  [GsMethod
| > OOP 7201025]
| > 45 FSGsSocket >> next: @37 line 30  [GsMethod OOP 219493889]
| > 46 FSGsSocket >> next @2 line 5  [GsMethod OOP 219491841]
| > 47 FSRecordStruct >> readFromStream: @2 line 5  [GsMethod OOP
| > 219522305]
| > 48 FSRecordStruct class >> readFromStream: @2 line 2  [GsMethod OOP
| > 219465473]
| > 49 FSGsSocket >> nextRecordStruct @2 line 6  [GsMethod OOP
| > 499268097]
| > 50 FSConnection >> nextAppRecordStruct @2 line 6  [GsMethod OOP
| > 219650305]
| > 51 FSConnection >> nextAppRecord @1 line 7  [GsMethod OOP
| > 219650561]
| > 52 FSConnection >> makeActive @2 line 6  [GsMethod OOP 499286785]
| > ...
| >
| >
| > Without more information, I'd guess the that the "Unreportable
| > ERROR" are coming someone is hitting your server vms with invalid
| > FASTCgi packets ... presumably you have correctly formed packets
| > coming in because the web-site is being served correctly , but the
| > fact that FastCGI is getting a error while reading records ...
| > #makeActive is interpretting the incoming bytes...
| >
| > So there are two different errors involved:
| >
| >  the commit conflict coming from valid fastcgi packets
| >  the "Unreportable ERROR" coming from presumably invalid fastcgi
| >  packets
| >
|
|   Interesting. How in the world am I being hit with invalid fastcgi
|   traffic? Am I under attack?
| Yes, the website is up and serving traffic correctly.
|
|   Funny that the Rc-Write-Write error is somehow related to session
|   and document handlers….
|
|   Larry
|
|
| > Dale
| >
| > ----- Original Message -----
| > | From: "Lawrence Kellogg" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Monday, July 9, 2012 5:10:30 PM
| > | Subject: Re: [GS/SS Beta] Far worse problems…
| > |
| > | Thanks for the code snippet. Well, here is the stack. I'm
| > | mystified
| > | by it.
| > |
| > |
| > | 1> greater than the ending index <0>.-----------
| > | -----------  Unreportable ERROR Encountered:
| > | 2012-07-09T17:05:53.9349250793457-07:00InterpreterError 2089: An
| > | index range was specified for a sequenceable collection with the
| > | starting index <1> greater than the ending index <0>.
| > | 1 FSGsSocketServer >> notifyUnreportableError: @2 line 4
| > |  [GsMethod
| > | OOP 472284673]
| > | 2 ComplexBlock in FSConnection >> notifyUnreportableError: @4
| > | line 6
| > |  [GsMethod OOP 219648257]
| > | 3 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
| > | 10065409]
| > | 4 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| > | 10062081]
| > | 5 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod
| > | OOP
| > | 9005057]
| > | 6 FSConnection >> notifyUnreportableError: @6 line 7  [GsMethod
| > | OOP
| > | 219648257]
| > | 7 ComplexBlock in FSConnection >> handleError: @28 line 23
| > |  [GsMethod
| > | OOP 499287553]
| > | 8 ExceptionHandler >> caughtExceptionWithAction: @5 line 4
| > |  [GsMethod
| > | OOP 10065153]
| > | 9 ComplexBlock in ExceptionHandler >>
| > | caughtEx:number:cat:args:handler: @12 line 13  [GsMethod OOP
| > | 10064641]
| > | 10 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > |  [GsMethod
| > | OOP 2304001]
| > | 11 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > |  [GsMethod
| > | OOP 2304001]
| > | 12 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line
| > | 14
| > |  [GsMethod OOP 10064641]
| > | 13 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12
| > |  [GsMethod OOP 10062081]
| > | 14 Exception >> _signal:number:args: @2 line 7  [GsMethod OOP
| > | 2327041]
| > | 15 ExceptionA >> signal @14 line 41  [GsMethod OOP 10057473]
| > | 16 GsError >> signal @3 line 5  [GsMethod OOP 20972033]
| > | 17 ExceptionA >> signal: @3 line 12  [GsMethod OOP 10050817]
| > | 18 ExceptionA class >> signal: @2 line 3  [GsMethod OOP 11895041]
| > | 19 GsError class >> signal: @3 line 5  [GsMethod OOP 21805313]
| > | 20 UserDefinedError class >> signal: @3 line 4  [GsMethod OOP
| > | 22234625]
| > | 21 Object >> error: @3 line 7  [GsMethod OOP 19075073]
| > | 22 FSGsSocket >> nextPutAll: @10 line 6  [GsMethod OOP 219493633]
| > | 23 FSRecordStruct >> writeToStream: @14 line 14  [GsMethod OOP
| > | 219521281]
| > | 24 ComplexBlock in FSRecordSeries >> writeToStream: @7 line 3
| > |  [GsMethod OOP 218670849]
| > | 25 Collection >> do: @5 line 10  [GsMethod OOP 1547777]
| > | 26 FSRecordSeries >> writeToStream: @8 line 3  [GsMethod OOP
| > | 218670849]
| > | 27 FSConnection >> writeRecord: @6 line 3  [GsMethod OOP
| > | 219649793]
| > | 28 ComplexVCBlock in FSConnection >> handleError: @25 line 21
| > |  [GsMethod OOP 499287553]
| > | 29 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
| > | 10065409]
| > | 30 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| > | 10062081]
| > | 31 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8
| > |  [GsMethod
| > | OOP 9005057]
| > | 32 FSConnection >> handleError: @29 line 22  [GsMethod OOP
| > | 499287553]
| > | 33 ComplexBlock in FSConnection >> safeServe @10 line 13
| > |  [GsMethod
| > | OOP 499288833]
| > | 34 ExceptionHandler >> caughtExceptionWithAction: @5 line 4
| > |  [GsMethod OOP 10065153]
| > | 35 ComplexBlock in ExceptionHandler >>
| > | caughtEx:number:cat:args:handler: @12 line 13  [GsMethod OOP
| > | 10064641]
| > | 36 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > |  [GsMethod
| > | OOP 2304001]
| > | 37 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > |  [GsMethod
| > | OOP 2304001]
| > | 38 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line
| > | 14
| > |  [GsMethod OOP 10064641]
| > | 39 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12
| > |  [GsMethod OOP 10062081]
| > | 40 Exception >> _signal:number:args: @2 line 7  [GsMethod OOP
| > | 2327041]
| > | 41 System class >> signal:args:signalDictionary: @5 line 13
| > |  [GsMethod OOP 3241473]
| > | 42 Object >> _error:args: @7 line 10  [GsMethod OOP 1926401]
| > | 43 SequenceableCollection >> copyFrom:to:into:startingAt: @4 line
| > | 14
| > |  [GsMethod OOP 3408129]
| > | 44 ByteArray >> copyFrom:to:into:startingAt: @3 line 11
| > |  [GsMethod
| > | OOP 7201025]
| > | 45 FSGsSocket >> next: @37 line 30  [GsMethod OOP 219493889]
| > | 46 FSGsSocket >> next @2 line 5  [GsMethod OOP 219491841]
| > | 47 FSRecordStruct >> readFromStream: @2 line 5  [GsMethod OOP
| > | 219522305]
| > | 48 FSRecordStruct class >> readFromStream: @2 line 2  [GsMethod
| > | OOP
| > | 219465473]
| > | 49 FSGsSocket >> nextRecordStruct @2 line 6  [GsMethod OOP
| > | 499268097]
| > | 50 FSConnection >> nextAppRecordStruct @2 line 6  [GsMethod OOP
| > | 219650305]
| > | 51 FSConnection >> nextAppRecord @1 line 7  [GsMethod OOP
| > | 219650561]
| > | 52 FSConnection >> makeActive @2 line 6  [GsMethod OOP 499286785]
| > | 53 FSConnection >> unsafeServe @3 line 7  [GsMethod OOP
| > | 219646465]
| > | 54 ComplexBlock in FSConnection >> safeServe @5 line 8  [GsMethod
| > | OOP
| > | 499288833]
| > | 55 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
| > | 10065409]
| > | 56 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| > | 10062081]
| > | 57 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod
| > | OOP
| > | 9005057]
| > | 58 ComplexVCBlock in FSConnection >> safeServe @8 line 9
| > |  [GsMethod
| > | OOP 499288833]
| > | 59 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
| > | 10065409]
| > | 60 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| > | 10062081]
| > | 61 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8
| > |  [GsMethod
| > | OOP 9005057]
| > | 62 ComplexVCBlock in FSConnection >> safeServe @11 line 12
| > |  [GsMethod
| > | OOP 499288833]
| > | 63 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > |  [GsMethod
| > | OOP 2304001]
| > | 64 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
| > |  [GsMethod
| > | OOP 2304001]
| > | 65 FSConnection >> safeServe @14 line 15  [GsMethod OOP
| > | 499288833]
| > | 66 FSConnection >> serve @1 line 4  [GsMethod OOP 219654145]
| > | 67 ComplexBlock in FSSocketServer >> listen: @9 line 15
| > |  [GsMethod
| > | OOP 219292673]
| > | 68 GsProcess >> _startPart2 @15 line 17  [GsMethod OOP 4501249]
| > | 69 GsProcess >> _start @1 line 9  [GsMethod OOP 4501761]
| > | On Jul 9, 2012, at 8:02 PM, Dale Henrichs wrote:
| > |
| > | > Lawrence,
| > | >
| > | > Whenever something like this happens, I always ask myself the
| > | > question: "what did I just change" ... it's almost certain that
| > | > the new behavior is the result of changes you made to the
| > | > system
| > | > ... Often a review of the changes combined with the error
| > | > messages
| > | > in the log (in the case commit conflicts) should point to the
| > | > offending code ... alternatively you could could back out your
| > | > code changes (reload the package versions from the previously
| > | > know
| > | > to work configuration) which should "fix the issues" ... then
| > | > you
| > | > can try to reproduce the problem in your sandbox and fix it
| > | > there
| > | > before reapplying the updates ...
| > | >
| > | > To get more information about the "Unreportable ERROR" you can
| > | > modify FSGsSocketServer>>notifyUnreportableError: (the likely
| > | > source of the log entry) to look like this:
| > | >
| > | >  notifyUnreportableError: aString
| > | > "unconditional logging to stdout"
| > | > | stdout stack |
| > | > stack := GsProcess stackReportToLevel: 300.
| > | > stdout := GsFile stdoutServer.
| > | > stdout nextPutAll: '-----------  Unreportable ERROR
| > | > Encountered:
| > | > ', DateAndTime now printString.
| > | > stdout nextPutAll: aString.
| > | > stdout cr.
| > | > stdout nextPutAll: stack.
| > | > stdout nextPutAll: '-----------'.
| > | > stdout cr.
| > | > stdout close.
| > | >
| > | > and get a stack dumped to the log...
| > | >
| > | > Dale
| > | >
| > | > ----- Original Message -----
| > | > | From: "Lawrence Kellogg" <[hidden email]>
| > | > | To: "GemStone Seaside beta discussion"
| > | > | <[hidden email]>
| > | > | Sent: Monday, July 9, 2012 4:42:13 PM
| > | > | Subject: [GS/SS Beta]  Far worse problems…
| > | > |
| > | > | Hello,
| > | > |   Actually, I have far worse problems than just hiding
| > | > |   changes in
| > | > |   the
| > | > |   Patch Browser. I just noticed that the log files for my
| > | > |   Gems
| > | > |   are
| > | > |   spewing out this:
| > | > |
| > | > |
| > | > |
| > | > |
| > | > | etryFailure
| > | > | Read-Write Conflicts...
| > | > | Write-Write Conflicts...
| > | > | Write-Dependency Conflicts...
| > | > | Write-ReadLock Conflicts...
| > | > | Write-WriteLock Conflicts...
| > | > | Rc-Write-Write Conflicts...
| > | > |     440885505
| > | > | Synchronized-Commit Conflicts...
| > | > | ----------- Commit failure - retrying LOG ENTRY:
| > | > | aSymbolDictionary-----------
| > | > | -----------  Unreportable ERROR Encountered:
| > | > | 2012-07-08T18:37:39.67828106880188-07:00InterpreterError
| > | > | 2089: An
| > | > | index range was specified for a sequenceable collection with
| > | > | the
| > | > | starting index <1> greater than the ending index
| > | > | <0>.-----------
| > | > | -----------  Unreportable ERROR Encountered:
| > | > | 2012-07-08T18:39:39.71508598327637-07:00InterpreterError
| > | > | 2089: An
| > | > | index range was specified for a sequenceable collection with
| > | > | the
| > | > | starting index <1> greater than the ending index
| > | > | <0>.-----------
| > | > | -----------  Unreportable ERROR Encountered:
| > | > | 2012-07-08T18:41:39.78475308418274-07:00InterpreterError
| > | > | 2089: An
| > | > | index range was specified for a sequenceable collection with
| > | > | the
| > | > | starting index <1> greater than the ending index
| > | > | <0>.-----------
| > | > | -----------  Unreportable ERROR Encountered:
| > | > | 2012-07-08T18:43:39.84294891357422-07:00InterpreterError
| > | > | 2089: An
| > | > | index range was specified for a sequenceable collection with
| > | > | the
| > | > | starting index <1> greater than the ending index
| > | > | <0>.-----------
| > | > |
| > | > | on and on and on...
| > | > |
| > | > | Help! What do I do? I took care of a walk back I add and
| > | > | actually
| > | > | have no idea what sequenceable collection is causing this
| > | > | problem.
| > | > | My system is up and running fine but all of these errors are
| > | > | being
| > | > | thrown.
| > | > |
| > | > |
| > | > |   Larry
| > |
| > |
|
|