[Glass] Nginx , FastCGI and GLASS problem

[Dale K. Henrichs]

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. 
]. 

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 
----- Original Message -----

| 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131205/593826eb/attachment-0001.html>