I think, that a not called ZincServer can be the reason for a backlog
problem - I have several Zinc server running in various gems and one of them is not called - and the backlog number for that task is increasing without end - as I understand this instance can be a reason for a not working garbage collection. That also means, that the low-level receiving part of Zinc should be rewritten for a regular timeout - and then after that timeout an abort should be executed ? Marten _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
This analysis seems to me to be exactly right.
Sent from my iPad > On Aug 30, 2015, at 12:36 AM, [hidden email] via Glass <[hidden email]> wrote: > > I think, that a not called ZincServer can be the reason for a backlog > problem - I have several Zinc server running in various gems and one of > them is not called - and the backlog number for that task is increasing > without end - as I understand this instance can be a reason for a not > working garbage collection. > > That also means, that the low-level receiving part of Zinc should be > rewritten for a regular timeout - and then after that timeout an abort > should be executed ? > > Marten > > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Marten,
How are you calling the ZincServer ... if you are using one of the startup scripts provided with GLASS, you will see the following pattern: System transactionMode: #manualBegin. Exception installStaticException: [:ex :cat :num :args | "Run the abort in a lowPriority process, since we must acquire the transactionMutex." [ GRPlatform current transactionMutex critical: [ GRPlatform current doAbortTransaction ]. System enableSignaledAbortError. ] forkAt: Processor lowestPriority. ] category: GemStoneError number: 6009 subtype: nil. System enableSignaledAbortError. "This thread is needed to handle the SigAbort exception, when the primary thread is blocked on an accept. Assuming default 60 second STN_GEM_ABORT_TIMEOUT, wake up at 30 second intervals." [ [ true ] whileTrue: [ (Delay forSeconds: 30) wait ]. ] forkAt: Processor lowestPriority. and this code is intended to avoid a CR backlog in a gem that is idle and waiting on a socket .... Dale On 8/30/15 6:49 AM, James Foster via Glass wrote: > This analysis seems to me to be exactly right. > > Sent from my iPad > >> On Aug 30, 2015, at 12:36 AM, [hidden email] via Glass <[hidden email]> wrote: >> >> I think, that a not called ZincServer can be the reason for a backlog >> problem - I have several Zinc server running in various gems and one of >> them is not called - and the backlog number for that task is increasing >> without end - as I understand this instance can be a reason for a not >> working garbage collection. >> >> That also means, that the low-level receiving part of Zinc should be >> rewritten for a regular timeout - and then after that timeout an abort >> should be executed ? >> >> Marten >> >> _______________________________________________ >> Glass mailing list >> [hidden email] >> http://lists.gemtalksystems.com/mailman/listinfo/glass > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |