<div dir="ltr">Marten, thank you for your response. <div><br></div><div>Yes, maybe the answer is to try a totally different way of delivering requests. How would, for example the RabbitMQ library, help to distribute the load better? If Apache or nginx does not have enough knowledge to decide how to distribute the requests, why would another delivery mechanism have better knowledge?</div><div><br></div><div>I am assuming your thinking of using an MQ based approach is based on the idea that there is a single queue that channels requests into a server that will then decide how to service these requests optimally. Is that correct? By optimally here I mean distribute the work fairly and process in parallel so that a full queue of requests are handled as quickly as possible. Do you think that it is necessary for such a server to know something about the requests so that it can handle them differently?</div><div><br></div><div>What I would like is to have a single queue, a pool of processes that can handle requests and a distributor that picks any process that is not busy to handle a request. If all processes are busy, wait for the first one that becomes available and give it the next request to handle. Easier said than done I suppose.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td width="400" valign="bottom"><p style="margin:0px;padding:0px"><span style="font-size:18px;color:rgb(146,148,151);font-family:Calibri,sans-serif;font-weight:700">Otto Behrens</span><br></p><p style="font-size:18px;font-weight:700;color:rgb(146,148,151);font-family:Calibri,sans-serif;margin:0px;padding:0px"><span style="font-size:14px;font-weight:300;margin:0px;padding:0px">+27 82 809 2375</span></p></td><td width="200" valign="middle"><img src="https://www.finworks.biz/signature/finworks-signature-logo.png" width="200" height="38" alt="FINWorks" style="display:block;border:0px;width:200px;height:38px;margin:0px;padding:0px"></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td height="5"></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium;border-bottom:1px solid rgb(200,28,36)"><tbody><tr><td height="15"></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td height="20"></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td width="15" valign="top" style="display:inline-block"><a href="http://za.linkedin.com/in/waltherbehrens" style="color:rgb(17,85,204)" target="_blank"><img src="https://www.finworks.biz/signature/finworks-linkedin-logo.png" width="15" height="15" alt="FINWorks" style="display:inline-block;border:0px;width:15px;height:15px;margin-top:1.5px;padding:0px"></a></td><td width="250" valign="top" style="display:inline-block"><a href="http://www.finworks.biz/" style="color:rgb(200,28,36);font-family:Calibri,sans-serif;margin-left:10px;margin-top:0px;padding-top:0px;font-size:11pt;display:inline-block" target="_blank">www.finworks.biz</a></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td height="10"></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td><p style="font-size:10px;color:rgb(146,148,151);font-family:Calibri,sans-serif;text-align:justify">Disclaimer & Confidentiality Note: This email is intended solely for the use of the individual or entity named above as it may contain information that is confidential and privileged. If you are not the intended recipient, be advised that any dissemination, distribution or copying of this email is strictly prohibited. FINWorks cannot be held liable by any person other than the addressee in respect of any opinions, conclusions, advice or other information contained in this email.</p></td></tr></tbody></table></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 22, 2023 at 10:45 AM Marten Felddtmann <m@feldtmann.online> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div>Hi,</div>
<div><br>
</div>
<div>this is a very interesting topic and
actually I do not find any good solution under Apache (or perhaps
nginx). I mentioned this in my talk at the London User Group last
month regarding Gemstone/S. Apache (perhaps also nginx) do not
have the knowledge to make the delivery of the http request in a
good way to Gemstone.</div>
<div><br>
</div>
<div>I had more or less luck, that the
modelling tool for Gemstone (I use) allows me to categorize the
API (HTTP) calls into different categories: normal, long and
memory and this works most of the time using the standard balancer
of Apache. Its getting more complicated, when the usage of a
server is getting higher and higher ... then there is theoretical
a point, where the whole communication collapses (in a notable way
of the end user: more and more UI errors a showing).</div>
<div><br>
</div>
<div>Even with these categories,
implementing background tasks in Gemstone/S solutions seems to be
a general suitable pattern (in the API oriented way) (so, the UI
is defining a background task with parameters and then it is
waiting for an event, that the work has been done).<br>
</div>
<div><br>
</div>
<div>The solution to this problem would be a
total different way of delivery the http requests to Gemstone.
Around 2012/15 there was an experimental http server mongel2
available, which works as a http-server and a zeromq backend. So
the backend processes pull their next request (however pull is
implemented). By using the available software it would be perhaps
more useful to use the RabbitMQ library from Gemstone and write a
mapper between http and rabbitmq.</div>
<div><br>
</div>
<div>As I mentioned above: I have a working
solution, but not a good solution - but it works now for more than
8 years.<br>
</div>
<div><br>
</div>
<div>My Gemstone/S solutions are all
API-oriented, sessions are persistent (so available in all
processes), UI is written in JS .</div>
<div><br>
</div>
<div>Marten<br>
</div>
<div><br>
</div>
<div>On 20.12.23 13:04, Otto Behrens via
Glass wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>We are using nginx to load balance in front of GemStone
that runs a Seaside application. Some of our requests run too
long (we are working hard to cut them down) and in general,
the time it takes to service a request in our application
varies between 0.1 and about 4 seconds. We are improving and
getting more towards the lower end of that. </div>
<div><br>
</div>
<div>Because of this, we use the least_conn directive and we
persist session state so that we could use any of our GemStone
upstream sessions to service a request. Requests are generally
load balanced to idle sessions and there are theoretically no
requests that wait for another to get serviced. Perhaps this
is not optimal and you have better suggestions. It has worked
ok for a long time, but should we consider another approach?</div>
<div><br>
</div>
<div>When our code misbehaves and a request takes let's say 60
seconds to handle, things go pear shaped (yes we want to
eliminate them). The user clicks "back" on the browser or
closes the browser and nginx picks it up with: </div>
<div>"epoll_wait() reported that client prematurely closed
connection, so upstream connection is closed too while sending
request to upstream"<br>
</div>
<div><br>
</div>
<div>We suspect our problem is: when this happens, it appears as
if nginx then routes requests to that same upstream, which is
unable to handle it because it is busy handling the previous
request (which is taking too long), even with some upstream
sessions sitting idle. Some users then end up with no
response.</div>
<div><br>
</div>
<div>Ideally, we would like to catch the situation in the
GemStone session and stop processing the request (when nginx
closes the upstream connection). Alternatively, we could set
timeouts long enough so that if the browser prematurely closes
the connection, nginx does not close the upstream connection. </div>
<div><br>
</div>
<div>Do you have a suggestion to handle this? Does it make sense
to get timeouts (which ones?) to align so that this does not
happen?</div>
<div><br>
</div>
<div>Thanks a lot</div>
<div>
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<table style="color:rgb(0,0,0);font-family:Times;font-size:medium" width="600" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td width="400" valign="bottom">
<p style="margin:0px;padding:0px"><span style="font-size:18px;color:rgb(146,148,151);font-family:Calibri,sans-serif;font-weight:700">Otto
Behrens</span><br>
</p>
<p style="font-size:18px;font-weight:700;color:rgb(146,148,151);font-family:Calibri,sans-serif;margin:0px;padding:0px"><span style="font-size:14px;font-weight:300;margin:0px;padding:0px">+27 82 809
2375</span></p>
</td>
<td width="200" valign="middle"><img src="https://www.finworks.biz/signature/finworks-signature-logo.png" alt="FINWorks" style="display: block; border: 0px; width: 200px; height: 38px; margin: 0px; padding: 0px;" width="200" height="38"></td>
</tr>
</tbody>
</table>
<table style="color:rgb(0,0,0);font-family:Times;font-size:medium" width="600" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td height="5"><br>
</td>
</tr>
</tbody>
</table>
<table style="color:rgb(0,0,0);font-family:Times;font-size:medium;border-bottom:1px solid rgb(200,28,36)" width="600" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td height="15"><br>
</td>
</tr>
</tbody>
</table>
<table style="color:rgb(0,0,0);font-family:Times;font-size:medium" width="600" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td height="20"><br>
</td>
</tr>
</tbody>
</table>
<table style="color:rgb(0,0,0);font-family:Times;font-size:medium" width="600" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td style="display:inline-block" width="15" valign="top"><a href="http://za.linkedin.com/in/waltherbehrens" style="color:rgb(17,85,204)" target="_blank"><img src="https://www.finworks.biz/signature/finworks-linkedin-logo.png" alt="FINWorks" style="display: inline-block; border: 0px; width: 15px; height: 15px; margin-top: 1.5px; padding: 0px;" width="15" height="15"></a></td>
<td style="display:inline-block" width="250" valign="top"><a href="http://www.finworks.biz/" style="color:rgb(200,28,36);font-family:Calibri,sans-serif;margin-left:10px;margin-top:0px;padding-top:0px;font-size:11pt;display:inline-block" target="_blank">www.finworks.biz</a></td>
</tr>
</tbody>
</table>
<table style="color:rgb(0,0,0);font-family:Times;font-size:medium" width="600" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td height="10"><br>
</td>
</tr>
</tbody>
</table>
<table style="color:rgb(0,0,0);font-family:Times;font-size:medium" width="600" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td>
<p style="font-size:10px;color:rgb(146,148,151);font-family:Calibri,sans-serif;text-align:justify">Disclaimer
& Confidentiality Note: This email is
intended solely for the use of the
individual or entity named above as it may
contain information that is confidential
and privileged. If you are not the
intended recipient, be advised that any
dissemination, distribution or copying of
this email is strictly prohibited.
FINWorks cannot be held liable by any
person other than the addressee in respect
of any opinions, conclusions, advice or
other information contained in this email.</p>
</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Glass mailing list
<a href="mailto:Glass@lists.gemtalksystems.com" target="_blank">Glass@lists.gemtalksystems.com</a>
<a href="https://lists.gemtalksystems.com/mailman/listinfo/glass" target="_blank">https://lists.gemtalksystems.com/mailman/listinfo/glass</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
</blockquote></div>