[Glass] Nginx , FastCGI and GLASS problem

[Mariano Martinez Peck]

On Thu, Dec 5, 2013 at 10:30 PM, Dale K. Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Johan and Mariano,
>
> For 3.1, I think the following should work in the startSeaside30_Adaptor
> script. NOTE, I've used `true ifTrue: [] ifFalse:[]` to enclose the
> new-style static exception handler that in addition to handling (and
> logging) the fact that a SigAbort was handled installs a handler for the
> RepositoryViewLost notification that dumps a stack so we can get more info
> about what the gem is doing when the lost ot is issued:
>
> true ifTrue: [.
> Transcript cr; show: 'New style SigAbort hanlder'.
> TransactionBacklog
>   addDefaultHandler: [ :ex |.
>     "Run the abort in a lowPriority process, since we must acquire the
>      transactionMutex."
>     Transcript cr; show: 'handled sigabort: ', DateAndTime now printString.
>     [
>       GRPlatform current transactionMutex
>         critical: [ GRPlatform current doAbortTransaction ].
>       TransactionBacklog enableSignalling ]
>         forkAt: Processor lowestPriority.
>       ex resume ].
>  RepositoryViewLost
>    addDefaultHandler: [ :ex |.
>      GRPlatform current logError: ex description title: 'Lost OT'
> shouldCommit: false.
>      ex pass ].
> TransactionBacklog enableSignalling.
> ] ifFalse: [
> Transcript cr; show: 'Old style SigAbort hanlder'.
> Exception.
>   installStaticException:.
>     [:ex :cat :num :args |
>       "Run the abort in a lowPriority process, since we must acquire the
>        transactionMutex."
>       Transcript cr; show: 'handled sigabort: ', DateAndTime now
> printString.
>       [
>         GRPlatform current transactionMutex.
>           critical: [.
>             GRPlatform current doAbortTransaction ].
>         System enableSignaledAbortError.
>       ] forkAt: Processor lowestPriority.
>     ]
>   category: GemStoneError
>   number: 6009
>   subtype: nil.
> System enableSignaledAbortError.
> ].
>
>

Thanks Dale, I have updated my code with that. But notice that you script
is full of dots where they should not be (maybe a weird copy paste from
your email client)...
Here is the version that works:



true ifTrue: [
Transcript cr; show: 'New style SigAbort hanlder'.
TransactionBacklog
  addDefaultHandler: [ :ex |
    "Run the abort in a lowPriority process, since we must acquire the
     transactionMutex."
    Transcript cr; show: 'handled sigabort: ', DateAndTime now printString.
    [
      GRPlatform current transactionMutex
        critical: [ GRPlatform current doAbortTransaction ].
      TransactionBacklog enableSignalling ]
        forkAt: Processor lowestPriority.
      ex resume ].
 RepositoryViewLost
   addDefaultHandler: [ :ex |
     GRPlatform current logError: ex description title: 'Lost OT'
shouldCommit: false.
     ex pass ].
TransactionBacklog enableSignalling.
] ifFalse: [
Transcript cr; show: 'Old style SigAbort hanlder'.
Exception
  installStaticException:
    [:ex :cat :num :args |
      "Run the abort in a lowPriority process, since we must acquire the
       transactionMutex."
      Transcript cr; show: 'handled sigabort: ', DateAndTime now
printString.
      [
        GRPlatform current transactionMutex
          critical: [
            GRPlatform current doAbortTransaction ].
        System enableSignaledAbortError.
      ] forkAt: Processor lowestPriority.
    ]
  category: GemStoneError
  number: 6009
  subtype: nil.
System enableSignaledAbortError.
].





> If this is happening in 2.4 (Johan), I'll have to do a little more
> research to see if there is an exception equivalent to RepositoryViewLost
> signalled.
>
> Dale
> ------------------------------
>
> *From: *"Johan Brichau" <johan at yesplan.be>
> *To: *"Mariano Martinez Peck" <marianopeck at gmail.com>
> *Cc: *glass at lists.gemtalksystems.com
> *Sent: *Thursday, December 5, 2013 9:09:46 AM
> *Subject: *Re: [Glass] Nginx , FastCGI and GLASS problem
>
> And were you being blocked outside of a transaction or not? Because that
> is what the error says. I am getting this from time to time and still
> looking for a reason.
>
>
> Johan (sent from my mobile)
>
> On 05 Dec 2013, at 17:48, Mariano Martinez Peck <marianopeck at gmail.com>
> wrote:
>
>
>
>
> On Thu, Dec 5, 2013 at 1:43 PM, Johan Brichau <johan at yesplan.be> wrote:
>
>> Mariano,
>>
>> The logs you show looks so similar to what I see in our gem logs when a
>> gem stops responding...
>> When it occurs, can you look at the object with the mentioned oop in the
>> write-write conflicts:
>>
>> > Write-Write Conflicts...
>> >     383168257
>> > Write-Dependency Conflicts...
>>
>> Inspect this:
>>
>>         Object _objectForOop: 383168257
>>
>> In my case this always opens on a dictionary with the #cacheTimeout
>> property in it.
>> Is this also true in your case?
>>
>>
> Thanks Johan for the advice. Unfortunately, I restarted everything did
> some changes etc so that OOP doesn't exist anymore :(
>
> But I will keep it in case I need it again.
>
> BTW, in my case I discovered the problem...it's that reading from
> /dev/random is blocking and when you run the OS in a virtual machine (like
> in my case I am using a VirtualBox vm) it is likely it will block for some
> time. There are lot of info about this in the internet.
> So at least that was my problem.
>
> Thanks,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131206/880934cd/attachment-0001.html>