nk4um

Hi Darren,

In particular, if I write an accessor that in turn does a simple synchronous context.source() call as a "sub-request" needed to compute it''s response, do I understand that the current thread does not necessarily (actually) *block* waiting for the response, but that it can actually go off and handle another response that might be available(?)  i.e. Something like this is done to make sure that the overall number of threads doesn''t get extreme?

When all requests are synchronous the same thread is used for all processing. Internally the request stack maps very closely to the java stack. In this simple case it is typically the transport thread that does the work right through all sub-requests. This is like regular java app servers.

NetKernel cannot reduce actual response times of generating a response simply from the addition of additional cores/threads alone - that would be magic (right? :).

Right!

That said as a programmer that might well be what you''d do as a first cut of a system and it would work. However as part of adding system constraints and tuning you might decide to introduce a throttle and various levels of your architecture or change some requests to asynchronous if you see places for optimization. This can lead to better scaling under load or leverage of extra cores utilised on a single request.

One other point which I think is potentially even more important though in the consideration of multi-core scaling is that of how the ROC abstraction plays a part regardless of the underlying mapping of requests to threads. That is when using mostly stateless endpoints and working with immutable representations rather that mutable objects, much, in fact just about all user level synchronization goes away and this to very good scaling. Only the kernel and persistent resources need to have synchronization and these are very small and optimized pieces of code.

Cheers, Tony

Just wanted to get clarification on how the threading works in Netkernel -

In particular, if I write an accessor that in turn does a simple synchronous context.source() call as a "sub-request" needed to compute it''s response, do I understand that the current thread does not necessarily (actually) *block* waiting for the response, but that it can actually go off and handle another response that might be available(?)  i.e. Something like this is done to make sure that the overall number of threads doesn''t get extreme?

If that''s too techie I guess more to the point of my question:  If I as a programmer don''t intentionally submit asynchronous sub-requests from an accessor where possible, i.e. to get multiple requests going at the same time, in that case are the benefits of NetKernel really much like java app servers/servlets - i.e. that NetKernel can allow multiple requests through the accessor and therefore high numbers of simultaneous clients, but without me thinking about how to run things in parallel and making use of asynchronous requests explicitly, NetKernel cannot reduce actual response times of generating a response simply from the addition of additional cores/threads alone - that would be magic (right? :).

Just something I''ve never been 100% clear on...