--- On Thu, 4/1/10, Adam Heath <[email protected]> wrote: > Adrian Crum wrote: > > --- On Thu, 4/1/10, Adam Heath <[email protected]> > wrote: > >> Adrian Crum wrote: > >>> --- On Thu, 4/1/10, Adam Heath <[email protected]> > >> wrote: > >>>> Adrian Crum wrote: > >>>>> --- On Thu, 4/1/10, Adam Heath <[email protected]> > >>>> wrote: > >>>>>> Adrian Crum wrote: > >>>>>>> I multi-threaded the data load > by > >> having one > >>>> thread > >>>>>> parse the XML files > >>>>>>> and put the results in a > queue. > >> Another > >>>> thread > >>>>>> services the queue and > >>>>>>> loads the data. I also > multi-threaded > >> the > >>>> EECAs - but > >>>>>> that has an issue > >>>>>>> I need to solve. > >>>>>> We need to be careful with that. > >>>> EntitySaxReader > >>>>>> supports reading > >>>>>> extremely large data files; it > doesn't > >> read the > >>>> entire > >>>>>> thing into > >>>>>> memory. So, any such event > dispatch > >> system > >>>> needs to > >>>>>> keep the parsing > >>>>>> from getting to far ahead. > >>>>> http://java.sun.com/javase/6/docs/api/java/util/concurrent/BlockingQueue.html > >>>> Not really. That will block the > calling > >> thread when > >>>> no data is available. > >>> Yeah, really. > >>> > >>> 1. Construct a FIFO queue, fire up n consumers > to > >> service the queue. > >>> 2. Consumers block, waiting for queue > elements. > >>> 3. Producer adds elements to queue. Consumers > >> unblock. > >>> 4. Queue reaches capacity, producer blocks, > waiting > >> for room. > >>> 5. Consumers empty the queue. > >>> 6. Goto step 2. > >> And that's a blocking algo, which is bad. > >> > >> If you only have a limited number of threads, then > anytime > >> one of them > >> blocks, the thread becomes unavailable to do real > work. > >> > >> What needs to happen in these cases is that the > thread > >> removes it self > >> from the thread pool, and the consumer thread then > had to > >> resubmit the > >> producer. > >> > >> The whole point of SEDA is to not have unbounded > resource > >> usage. If a > >> thread gets blocked, then that implies that > another new > >> thread will be > >> needed to keep the work queue proceeding. > > > > Why Events Are A Bad Idea (for high-concurrency > servers) - http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf > > > > An interesting refutation to SEDA. > > (haven't read that yet) > > == > mkdir /dev/shm/ofbiz-runtime > mount --bind /dev/shm/ofbiz-runtime > $OFBIZ_HOME/runtime/data > == > > Quick speedup. /dev/shm is a tmpfs(on linux anyways), > basically a > filesystem kept only in ram.
== goto /local/neighborhood/best-buy purchase $CPU, $RAM, $RAID echo Problem solved == Works on Windows.
