#1061 closed feature (fixed)

rasmgr behavior when a client requests a server, but not server is available.

Reported by: atoader Owned by: atoader
Priority: major Milestone: 9.2
Component: rasmgr Version: development
Keywords: Cc: dmisev, mdumitru, vmerticariu, gmerticariu, pbaumann
Complexity: Medium

Description

What should happen in rasmgr when a request for a new server is received but there are no available servers?

  1. Should the client be forced to wait until a server becomes available?
  2. Should rasmgr attempt to find an available server a fixed number of times with a fixed timeout between attempts, and if no server is found return an error?
  3. Should rasmgr return an error to the client announcing that no server is available?

At the moment, option 3 is implemented.

Feel free to suggest alternative behaviours.

Change History (7)

comment:1 Changed 22 months ago by pbaumann

As we cannot keep open a client request for indefinite time, (1) is not good now. However, it might be in future when we think of async requests. So I suggest to leave (3) as it is, and take up this discussion when it comes to async implementation.

comment:2 Changed 22 months ago by dmisev

I thought the new rasmgr automatically starts/shutdowns rasservers? Or this wasn't implemented?

comment:3 Changed 22 months ago by dmisev

In any case, I think 2. would be nice and probably trivial to implement (with some exponential backoff sort of retrying algorithm though).

comment:4 follow-up: Changed 22 months ago by atoader

The new rasmgr automatically starts/shutsdown servers. The way it works is that you specify a maximum number of servers in rasmgr.conf and it will start servers, depending on load, up to that maximum number.
Now, when you start a rasserver process, because there is no function to determine when the process has started, rasmgr waits for a registration message from the server announcing that it is online. This incurs a delay of several milliseconds. Also, this process is fully controlled by server manager inside rasmgr that has a thread that checks, at a set interval, the list of registered servers and starts or shutsdown servers.

Because the client request is instant and there is no waiting involved, there is no time for the process described above to take place.

Last edited 22 months ago by atoader (previous) (diff)

comment:5 in reply to: ↑ 4 Changed 22 months ago by dmisev

Replying to atoader:

Now, when you start a rasserver process, because there is no function to determine when the process has started, rasmgr waits for a registration message from the server announcing that it is online. This incurs a delay of several milliseconds. Also, this process is fully controlled by server manager inside rasmgr that has a thread that checks, at a set interval, the list of registered servers and starts or shutsdown servers.

Because the client request is instant and there is no waiting involved, there is no time for the process described above to take place.

Are you referring to ticket #1059? Your comment doesn't seem like it belongs here.

comment:6 Changed 22 months ago by atoader

Yes, sorry. I mixed the tickets.

comment:7 Changed 21 months ago by atoader

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.