A question about ChatRoom in Connections Issue #2

[rc_hz]

I'm not sure I understand the question. All calls can block if the server doesn't respond, this is nothing specific to Glacier2. The same would happen if you would call the server directly. To avoid this, you typically set timeouts.

I means that if one Server behind Glacier2 runs very slowly, then other Servers will be affected in some circumstance.

Please have a look at the attach file first. This is my explanation:
Suppose there are many threads in each Client sending requests to different Servers (Server1/Server2) simultaneously We know that in Glacier2, there is a RequestQueue1 corresponding to Client1, and that all requests from Client1 are cached in RequestQueue1.

Suppose there are 3 requests in RequestQueue1 now: request-a(to Server1) , request-b(to Server2) , request-c(to Server2) . If Server1 runs very slowly for some reason and has no time to receive requests on the wire, the AMI call (request-a) to Server1 in RequestQueue1 will be blocked and other requests (request-b/reqeust-c) to other Servers(Server2) will have to wait. That is, the slowing Server1 has a bad effect on other Servers(Server2). It’s very terrible.

Now every Client has a corresponding RequestQueue in Glacier2 and all requests to different Servers from the same Client are mixed in a RequestQueue. I think that this is the core of problem. Maybe if we put all requests to the same Server from different Clients in a RequestQueue instead of putting all requests to different Servers from the same Client in a RequestQueue can solve the problem.

[rc_hz]

Now every Client has a corresponding RequestQueue in Glacier2 and all requests to different Servers from the same Client are mixed in a RequestQueue. I think that this is the core of problem. Maybe if we put all requests to the same Server from different Clients in a RequestQueue instead of putting all requests to different Servers from the same Client in a RequestQueue can solve the problem.

Maybe the best solution is set a timeout to the AMI calls in the RequestQueue. If any AMI call times out, just put the request at the bottom in the RequestQueue and retry it next time. Maybe 2 new properties can control this:
Glacier2.AMI.timeout=xxx
Glacier2.AMI.retrys=yyy

[matthew]

What you say is technically correct, its not a scenario that Glacier2 is designed to protect against. Glacier2 isn't meant to protect clients from misbehaving servers, it is meant to protect servers against misbehaving clients. In real world applications client can be expected to misbehave for a whole host of reasons. Servers in a protected environment should be well behaved. If they are not, then they should be fixed.

Best Regards, Matthew

[rc_hz]

What you say is technically correct, its not a scenario that Glacier2 is designed to protect against. Glacier2 isn't meant to protect clients from misbehaving servers, it is meant to protect servers against misbehaving clients. In real world applications client can be expected to misbehave for a whole host of reasons. Servers in a protected environment should be well behaved. If they are not, then they should be fixed.

Best Regards, Matthew

I don't agree with you.
There are all kinds of servers behind Glacier2. It's very normal that some runs very fast while some runs slowly because they may do more things in a request than other servers do. Both of them are not misbehaving servers.

[matthew]

If the server cannot keep up with the client then its misbehaving and you should either deploy more of them, or architect them differently. In our view it is not the job of Glacier2 to protect the client against this situation.

Regards, Matthew

[rc_hz]

If the server cannot keep up with the client then its misbehaving and you should either deploy more of them, or architect them differently. In our view it is not the job of Glacier2 to protect the client against this situation.

Regards, Matthew

I am sorry, but I still can not agree with you and I can not convince you either. What I can do is holding on my opition.

[matthew]

There are lots of solutions to your issue
- Since you have the source to Glacier2 itself so you may make whatever changes you feel are necessary.
- If you don't want to modify Glacier2, then you can write a custom service to handle the back end message queuing for the slow servers.

Best Regards, Matthew

[rc_hz]

There are lots of solutions to your issue
- Since you have the source to Glacier2 itself so you may make whatever changes you feel are necessary.
- If you don't want to modify Glacier2, then you can write a custom service to handle the back end message queuing for the slow servers.

Best Regards, Matthew

Thank you, Matthew. I am just a fan of ICE and up to now I haven't yet use ICE in my projects because I knew Ice until last year's autumn. I am now just reading ICE's documents and source code and raising my questions and I hope these can be helpful to ICE.