Web request problem on server with two Glass environment

Johan,

On Apr 17, 2012, at 8:28 AM, Johan Brichau wrote:

> Larry,
>
> Great news ;-)

  Yes, indeed!

>
> Don't forget to monitor the other fastcgi gems as well (I'm assuming you are running 3 fastcgi gems)
>

  Well, I'm running three fastcgi gems now! ;-) I set up the same logic in the monit file to start and stop
fastcgi gems on 9002 and 9003.

  I have been testing by sending kill -9 to some of the fastcgi gems. If three of them are running, and I
kill one, shouldn't I still be able to get a session to my server through another fastcgi gem?

It seems to me that sometimes I cannot reconnect to the server until the killed gem has been recycled. How does this work?
 

> Similarly, the maintenance gem is important and I also monitor the size of the extent using monit.
>

  Yes, the maintenance gems are started and stopped by my commands. I will look into monitoring the size of the extent.

  Larry

On 17 Apr 2012, at 15:31, Lawrence Kellogg wrote:

>  I have been testing by sending kill -9 to some of the fastcgi gems. If three of them are running, and I
> kill one, shouldn't I still be able to get a session to my server through another fastcgi gem?
>
> It seems to me that sometimes I cannot reconnect to the server until the killed gem has been recycled. How does this work?

That depends on how you configured the front-end webserver. Normally, a standard setup should be round-robin load balancing the fastcgi gems. If one fastccgi backend does not accept a request, it should automatically take the next one.

What front-end webserver are you using?

Johan

On Apr 17, 2012, at 10:22 AM, Johan Brichau wrote:

Johan,
  I'm using nginx. Ah, thanks for reminding me! I needed to add two more lines to the nginx.conf file for ports 9002 and 9003 to make sure that
the round robin scheduling takes place if one of the fastcgi gems goes down.
 
  This is brilliant, and works very well. Now, I just need a hundred thousand users. ;-)

  Larry


>
> Johan