Re: About massive-persistent-connection and service priority

On 28-12-2012 10:31, Guozhe wrote:

>    Multiplex: cannot deal with circular-request. For example, Client-> A->B->C->A,
> unless use One-way-call, it would block. If we want get return value, multiplex with
> one-way cannot resolve it.

This problem also occurs in another situation that's not related to the type of server
you're using. See the 'deadlock' example. It's unfortunate, but for now a thing to be
aware of: design your object interactions in such a way that they don't need to call
eachother circularly.



>    ThreadPool: for the limit of THREADPOOL_MAXTHREADS, if there are many
> persistent-connection(persistent : one proxy connected to the server may last long time
> before close), more than THREADPOOL_MAXTHREADS , the server cannot response to new
> connected proxy(all thread is assigned already and no proxy released yet). Yes you can
> make larger THREADPOOL_MAXTHREADS, but if the number of thread more than 1000, it
> increases system overhead greatly.
> 
>    Think about this scene: one proxy connected to the server and make a remote call
> every 5 mins, the thread assigned to it will spend almost the time in recv() [it block
> here if no request come] but cannot process other proxy’s request. However, if we use
> Multiplex type, we will be blocked in circular-request as mentioned before.
> 
> So, I have some suggestion about this problem—merge the Multiplex and Thread type. That
> is: a Server works like Multiplex but not handle request itself. It has a threadpool
> which contain many worker thread. When the server select a client socket that ready to
> read, put the socket to the threadpool to handle and delete it from current socket list.
> Every worker thread do handleRequest() once(should modify the job class, when do job(),
> it not entry a endless-loop but do once handleRequest) and wait to get another job.
> 
> By doing this, it can deal with many proxy using 10 or more threads, depending on the
> number of request arriving at the same time.

I like the idea but it is a complex part of the system and very tricky to get right.
Thorsten's comment provides a possible workaround for the issue. Currently I don't have
the time to implement a new dispatch mechanism in Pyro4 and test it thorougly. So for
the time being I rather keep people such as Thorsten pleased with the stable (though
limited) working of the existing two dispatchers. Patches are welcome though :-)
(but keep in mind, if there comes a time we do add a new dispatcher, it should have zero
changes to the existing code if possible)

Best practice until then: don't keep your proxy objects lingering around too long. If
you know they're not being used again soon after, _pyroRelease them, or use them from
within a context manager.


> There is another issue: services may have priority(high, medium or low) when they
> registered. A high-level service request may be processed before a low-level request if
> they all in job-queue. We can use priority-queue. But the problem is: if there are many
> high-level request and a little medium or low-level request, the low level request may
> hang until all the high-level request are processed. So how to assign a little time to
> the lower-level request? My suggestion is make three type of worker thread, control the
> number of each type.

I don't like this (Pyro's not the place to introduce a task scheduler).


Irmen



------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912