Opened 9 years ago

Closed 9 years ago

#1061 closed feature (fixed)

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

Reported by: Alex Toader Owned by: Alex Toader
Priority: major Milestone: 9.2
Component: rasmgr Version: development
Keywords: Cc: Dimitar Misev, Alex Dumitru, Vlad Merticariu, George Merticariu, Peter Baumann
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 by Peter Baumann, 9 years ago

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 by Dimitar Misev, 9 years ago

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

comment:3 by Dimitar Misev, 9 years ago

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 by Alex Toader, 9 years ago

It does that. 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 shuts down 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.

Version 0, edited 9 years ago by Alex Toader (next)

in reply to:  4 comment:5 by Dimitar Misev, 9 years ago

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 by Alex Toader, 9 years ago

Yes, sorry. I mixed the tickets.

comment:7 by Alex Toader, 9 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.