[Glass] Nginx , FastCGI and GLASS problem

Fri Dec 6 08:00:52 PST 2013

----- Original Message -----

| From: "Mariano Martinez Peck" <marianopeck at gmail.com>
| To: "Johan Brichau" <johan at yesplan.be>
| Cc: glass at lists.gemtalksystems.com
| Sent: Thursday, December 5, 2013 5:27:04 PM
| Subject: Re: [Glass] Nginx , FastCGI and GLASS problem

| On Thu, Dec 5, 2013 at 2:09 PM, Johan Brichau < johan at yesplan.be >
| wrote:

| | And were you being blocked outside of a transaction or not?
| 
| Sorry Johan, I didn't understand the question.
| But yes, I think I was being block outside the transaction.
I guess the fundamental question is why are you out of transaction? In the normal seaside case the gem is sitting on a socket accept and it is outside of transaction while waiting for a connection ... when the stone decides that a session needs to abort, it signals the sigabort and the little background process is supposed to wake up and allow the sigabort to be processed .. 

In Johan's case I am suspicious that the gem process may be slow to respond on a loaded system, but that is only a guess ... 

In your case, it seems that you've described a scenario, where you are getting this error ... while doing processing ... if that is truly the case then we need to understand how you got "outside of transaction" ... two possibilities come to mind: forking a process while doing http request processing; or doing an explicit abort/commit whild doing http processing ... 

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

| --
| 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/20131206/b5010a95/attachment-0001.html>