Strange errors with SortedCollection instances ...

I've here an instance of GS/S 3.3.0 running and when running 100 clients against my server instance (actually only one gem http server) I sometimes get the following error when using instances SortedCollection.

I've a statement like:

addresses remove: aCATIAddressQueueMembership ifAbsent:[ nil ]

and the remove:ifAbsent: method throws an exception:

a OffsetError occurred (error 2003), reason:objErrBadOffsetIncomplete, max:10165 actual:10166

Within remove:ifAbsent: the sytem crashes in SortedCollection>>remove:ifAbsent: @3 line 13 which is:

index := self indexOf: oldObject

which leads to a call to SortedCollection>at: @5 line 12 with a value of 10166

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

No, it was a complete new installation and the code was imported via Topaz-scripts - I can run my tests several times and this happens not always ... (actually only two times in 4 days).

Marten

Mariano Martinez Peck <[hidden email]> hat am 19. Juni 2016 um 18:00 geschrieben:

Was this on a stone upgraded from an older Gemstone version? Because I read some issue with SortedCollection migrations in the  mailing list...

On Sun, Jun 19, 2016 at 12:26 PM, Marten Feldtmann via Glass <[hidden email]> wrote:

I've here an instance of GS/S 3.3.0 running and when running 100 clients against my server instance (actually only one gem http server) I sometimes get the following error when using instances SortedCollection.

I've a statement like:

addresses remove: aCATIAddressQueueMembership ifAbsent:[ nil ]

and the remove:ifAbsent: method throws an exception:

a OffsetError occurred (error 2003), reason:objErrBadOffsetIncomplete, max:10165 actual:10166

Within remove:ifAbsent: the sytem crashes in SortedCollection>>remove:ifAbsent: @3 line 13 which is:

index := self indexOf: oldObject

which leads to a call to SortedCollection>at: @5 line 12 with a value of 10166

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Marten,

Is there any chance you have forked Smalltalk processes in that one gem?

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

I use the GEM only for Zinc-HTTP-Requests - nothing more - at least I know of - and some external C calls.

Marten

Richard Sargent <[hidden email]> hat am 19. Juni 2016 um 21:39 geschrieben:

Hi Marten,

Is there any chance you have forked Smalltalk processes in that one gem?

On Jun 19, 2016 8:26 AM, "Marten Feldtmann via Glass" <[hidden email]> wrote:

I've here an instance of GS/S 3.3.0 running and when running 100 clients against my server instance (actually only one gem http server) I sometimes get the following error when using instances SortedCollection.

I've a statement like:

addresses remove: aCATIAddressQueueMembership ifAbsent:[ nil ]

and the remove:ifAbsent: method throws an exception:

a OffsetError occurred (error 2003), reason:objErrBadOffsetIncomplete, max:10165 actual:10166

Within remove:ifAbsent: the sytem crashes in SortedCollection>>remove:ifAbsent: @3 line 13 which is:

index := self indexOf: oldObject

which leads to a call to SortedCollection>at: @5 line 12 with a value of 10166

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

The problem seems to be solved - due an own simple error I made:

The SortedCollection was build/sorted based on an attribute of  "complex" domain objects hold in that collection. I changed that attribute and after that (of course) I was not able to find the whole domain object any more and no way to remove it.

The correct way is: remove the domain object temporarly from that collection, change the domain attribut and add it back to that collection.

How is this handled when using indices on collections ?

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

How is this handled when using indices on collections ?

When updating an object that is used in an index, no messages are sent (except for Selector-based path terms) as the object state is directly accessed. Additionally the implementation is tolerant of nils being encountered along an access path .... At the lowest levels the index code detects that an instance variable associated with an index is being modified and the index is updated in anticipation of the new value (see Object>>_modifyingInstVarAtOffset:to:) ... the "update" involves removing the old index entry for the old value and adding a new entry for the new value --- if there is a nil along the path then the new entry is not created ...

Dale

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass