--- On Thu, 4/1/10, Adam Heath <[email protected]> wrote: > >> Nope, not good enough. It would be possible > for the > >> producer thread > >> to stuck for a long time, > producing/consuming. If > >> there are several > >> such workflows like this in the thread pool, then > the > >> threads become > >> unavailable for doing other work. > > > > Are we talking about theoretical software or OFBiz? > What thread pool? The application server's? I have been > referring to the existing OFBiz entity import/export code. > If an entity import takes n mS in the current > single-threaded code, and the same import takes n/x mS using > multi-threaded code, then hasn't the performance improved? > > Data loading can take place from webtools. And > several requests could > be submitted at once. There's no reason to try and > process them all > at the same time, if the cpu is loaded. Just queue up > the requests.
Like SEDA or my JMS idea. In other words, theoretical. > I'm not suggesting we go thru and change ofbiz to some kind > of > segmented event dispatcher. But the basic > infrastructure is simple > enough to write, it doesn't hurt to do it right in the > first place. Simpler yet is to use a BlockingQueue for this one task. I'm not disagreeing with you - it would be cool to have a SEDA-style application. Instead, I'm advocating baby steps. From my perspective, it is easier to try a simple multi-threaded approach and see if it causes any problems. If that works okay, then you can make it more sophisticated. Multiple simultaneous huge entity import requests under heavy load sounds like an unlikely scenario. Is there a real need to design for that?
