my option about AMD

[rc_hz]

Case 2:

You want to queue up the requests internally in the server for processing to avoid blocking clients. This case can be handled by using the Glacier2 router in buffered mode and letting it do the queuing.

In the view of Ice's users, the simpler, the better. If a Server and a Client are enough, why should a Glacier2 router be deployed?

Case 3:

You want to do special case processing on the queue, as you have suggested with the priority. However, this case cannot be handled in such a generic way by the Ice runtime, so therefore you would have to write this special case code yourself.

No, this case can be handled in a generic way by the Ice runtime. It can be handled in AMDThreadPool.

...without adding more burden to the Ice core and code generators...

The burden on Ice's slice2cpp in my post13 is equal to the burden on Ice's slice2cpp in my post12.

[rc_hz]

In general , AMD is more efficient and scalable than synchronized method dispatch.
I think, if the AMD operation don't call any other AMI operation, then the server can do like this:

1)One or more threads just get requests off the wire and cached it in a queue.
(Many further things can be done, such as : flow control, priority control, timeout control...)
(And it can solve this question: http://www.zeroc.com/vbulletin/showt...&highlight=AMI)

2)Another AMDThreadPool's threads get a reqeust from the queue, process it and send back the response to the client.

[matthew]

yes, this is what i want to do. It has the following advantages:
1) programmers need only write code5 (in my post13) and don't need to care about thread management.
2) If the server has many AMD operations, then they can share a single AMD thread pool. Its size can be controlled by a property such as Ice.AMDThreadPool.size= 10.


This is what AMD's internal meaning. By caching requests and freeing up the thread in the Ice dispatch pool as quickly as possible, the server can handle 100 requests with only 10 threads.

What do you mean by "handle"? If the server does long running operations on all of the requests the server is not handling the load any better than it would just by using the thread pool that the Ice runtime already provides. In fact you would make the performance worse due to all of the context switching that you've introduced.

In general , AMD is more efficient and scalable than synchronized method dispatch.
I think, if the AMD operation don't call any other AMI operation, then the server can do like this:

1)One or more threads just get requests off the wire and cached it in a queue.
(Many further things can be done, such as : flow control, priority control, timeout control...)
(And it can solve this question: http://www.zeroc.com/vbulletin/show...5&highlight=AMI)

2)Another AMDThreadPool's threads get a reqeust from the queue, process it and send back the response to the client.

AMD is certainly more flexible than using regular synchronous requests. However, that flexibility comes at cost as you've pointed out.

In the view of Ice's users, the simpler, the better. If a Server and a Client are enough, why should a Glacier2 router be deployed?

To handle security issues, and allowing the buffering to handle network blocking due to a busy client or server. If you want to see all of the benefits of using Glacier2 I would recommend reading the articles I wrote in Connections 1 & 2.

Consider the code that you pasted. If the AMD callbacks ice_response() or ice_exception() block due to a network problem you've just gone and tied up a thread in your processing thread pool... If you use Glacier2 (with buffered mode) this problem is avoided.

No, this case can be handled in a generic way by the Ice runtime. It can be handled in AMDThreadPool.

Quote:
Originally Posted by Matthew
...without adding more burden to the Ice core and code generators...

The burden on Ice's slice2cpp in my post13 is equal to the burden on Ice's slice2cpp in my post12.

The case cannot be handled in a generic way. As you've rightfully pointed out you may want to do very sophisticated priority management on the processing queue. How do you propose that we think of everything that the user might want to do with the queue items. The current implementation allows you manage it exactly as you see fit. Anything we provide will fall short, IMO.

Regards, Matthew

[rc_hz]

What do you mean by "handle"? If the server does long running operations on all of the requests the server is not handling the load any better than it would just by using the thread pool that the Ice runtime already provides.

"handle" just means that server can cached 100 requests with only 10 thread. If using synchonized method dispatch, other 90 requests have to be waiting. This is especially useful for AMI clients, I think!

In fact you would make the performance worse due to all of the context switching that you've introduced.

I think AMD has very little impact on the performance of the server. Additional work is just lock/unlock on the queue.

To handle security issues, and allowing the buffering to handle network blocking due to a busy client or server. If you want to see all of the benefits of using Glacier2 I would recommend reading the articles I wrote in Connections 1 & 2.

Consider the code that you pasted. If the AMD callbacks ice_response() or ice_exception() block due to a network problem you've just gone and tied up a thread in your processing thread pool... If you use Glacier2 (with buffered mode) this problem is avoided

I argee that Glacier2 can solve the problem. However, as I have mentioned in previous posts, Glacier2 is another process besides Server and Client. It's better if we can solve all these problems in Server process without another process. I think that simplicity is one of the most importantIce's design philosophies. Programmers do little and can get more.

The case cannot be handled in a generic way. As you've rightfully pointed out you may want to do very sophisticated priority management on the processing queue. How do you propose that we think of everything that the user might want to do with the queue items. The current implementation allows you manage it exactly as you see fit. Anything we provide will fall short, IMO.

I think that Ice can give a default implementation of priority management in AMDThreadPool, while programmers can override this implementation to meet their special purposes.