JS Client app & busy Omnis server

Hi Mayada,

> We do run a very complex form (as an app) with multiple tabs, so seeing
> this issue only at sites with high number of users might explain the need
> to put a cap on the connection # allowed to a single server.
To elaborate more, the app that I was working with had over 75+ remote forms and over a few hundred sub windows instantiated per user. 🙂
But we also maintained our own form stack too.

> Do you run a separate server to fork the connections to the right server
> when it reaches max number of conn.? or how do you control that?
We broke up the runtimes to smaller chunks, e.g. a 50user runtime was broken up into 10 5user runtime licences and we used Omnis LSP to then delegate incoming connections.

> BTW, I was able to reproduce the orphan connections myself when the server
> is busy with a high number of users..I called a form, it took a while to
> load, creating 2 connections (exactly same time, say one connection1 and
> the 2nd connection2), when I closed the app, only connection 2 is closed,
> leaving connection 1 open.
As Andrew has suggested to make sure that the onUnload is being called or added to the HTML side of things, but there is also the possibility of $canclose() we used $canclose a lot and if we didnt manage to get out of that cleanly it would leave an orphaned connection.

One other trick I’ve employed is that the logon form had a shorter timeout and once the user logged on successfully we’d bump up the timeout value of the remote task to 75 minutes or something. Also on the $destruct of the remote task we’d set the remote task’s $timeout to 1minute and then let the destruct run normally, this way we made extra sure that the remote task would terminate no matter what.

HTH

Regards,

Vik Shah
Director
Keys2Solutions
AU: +61 411 493 495
US: +1 (415) 413 4172
US: +1 (646) 583 2403

> On 22 Nov 2017, at 06:42, Mayada Al-Kishtini <malkishtini@gmail.com> wrote:
>
> Hi Vik,
>
> Thank you so much for sharing you solutions and suggestions…specially
> this one “1. monitor the #of connections per each omnis server. We capped
> that at 5/omnis server because the app was very complex.”
>
> We do run a very complex form (as an app) with multiple tabs, so seeing
> this issue only at sites with high number of users might explain the need
> to put a cap on the connection # allowed to a single server.
>
> Do you run a separate server to fork the connections to the right server
> when it reaches max number of conn.? or how do you control that?
>
> I’ll look more closely into your other suggestions and see what I can do
> with them.
>
> BTW, I was able to reproduce the orphan connections myself when the server
> is busy with a high number of users..I called a form, it took a while to
> load, creating 2 connections (exactly same time, say one connection1 and
> the 2nd connection2), when I closed the app, only connection 2 is closed,
> leaving connection 1 open.
>
> Thank you very much,
> Mayada
>
>
>
>
>
> On Tue, Nov 21, 2017 at 3:22 PM, Vik Shah <Vik@keys2solutions.com.au> wrote:
>
>> Hi Mayada,
>>
>> It sounds like either the client connections are not closing cleanly and
>> this could leave you with orphan connections. Without looking at your code
>> I can only say that the $destruct of the remote task isn’t finishing
>> properly, could be a $canclose somewhere that is preventing the shutdown of
>> connection and thus it lies wait till the remote task times out.
>>
>> WRT the licence consumption that is something that I’ve seen in the past,
>> could be coding/logic related issue too, once again the specifics cant be
>> ascertained easily only a proper code analysis can yield those answers.
>>
>> But, to curb what you are saying I implemented a mixed bag solution
>> comprising of omnis and non-omnis components. This solution would
>> 1. monitor the #of connections per each omnis server. We capped that at
>> 5/omnis server because the app was very complex.
>> 2. Allow remote management of task/user a.k.a we could message and/or kill
>> the connected user’s remote task session.
>> 3. Allowed statistical analysis of connections/server.
>> 4. Kill and restart servers dynamically using external scripts and
>> redirecting incoming connections to other omnis servers.
>> 5. Notified the in-house admins whenever a server was frozen or restarted
>> or failed to start.
>>
>>> Any advise on how to check for server state (busy or not) in the remote
>>> task, so one can code around it?
>>
>> There are remote task events that are triggered on evBusy, you could use
>> them. I devised another way of doing this, I would ping an ultra-thin
>> remote task that would quit instantly with a date/time message. If that
>> happened in under 1 second then the server is functioning if it took
>> longer, it usually meant that it was time for a kill-restart cycle.
>>
>> Hope that helps.
>>
>> Regards,
>>
>> Vik Shah
>> Director
>> Keys2Solutions
>> AU: +61 411 493 495
>> US: +1 (415) 413 4172
>> US: +1 (646) 583 2403
>>
>>
>>
>>
>>> On 22 Nov 2017, at 05:17, Mayada Al-Kishtini <malkishtini@gmail.com>
>> wrote:
>>>
>>> Hi $all,
>>>
>>> We are running into an issue with our web app at one of our sites, the
>>> issue appears when we have more than 35-40 simultaneous connections to
>> the
>>> OS server 6.3/64bit with 50 users license.
>>>
>>> What happens is when I try to connect to the web app at that site and the
>>> server has more than 35 connections (not sure of the exact number of
>>> connections that will cause the problem to appear, but something more
>> than
>>> 30-35), it takes a while to load the form and I when I check the log I
>>> notice that 2 remote task connections, sometimes 3 are established when
>> the
>>> form is loaded, then when a user disconnects from the server, that will
>>> close only one of the connections (the last one) and leave the rest as
>>> orphan connections and that will consume licenses and then the site will
>>> soon runs out of web licenses and we have to restart the server.
>>>
>>> My first time to encounter this issue, anyone else has seen any issue
>> like
>>> this before?
>>>
>>> Any advise on how to check for server state (busy or not) in the remote
>>> task, so one can code around it?
>>>
>>> Thank you,
>>> Mayada
>>> _____________________________________________________________
>>> Manage your list subscriptions at lists.omnis-dev.com
>>
>>
>>
>> _____________________________________________________________
>> Manage your list subscriptions at lists.omnis-dev.com
>>
> _____________________________________________________________
> Manage your list subscriptions at lists.omnis-dev.com

_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com