I cannot call anything I said a recommendation, as my experience in this area is limited. It's certainly what I would try, though. Actually, it's even what I am trying, in my own code.
I'm not real familiar with the internals of libuv. What I understood from the previous emails is that the thread pool is incapable of handling the load you're attempting to throw at it. I'm merely suggesting that since your threads are blocking when waiting for database responses, that perhaps using asynchronous database queries may be a better solution than threads. It would mean that your events would be on_read (socket) and on_read (database response). It would also eliminate the thread pool from the mix as being the limited resource. But, it might introduce design limitations you aren't prepared to do. If you're doing a lot of other processing in those threads, perhaps you'll benefit more by modifying (or building your own) thread-pool without the limitation of 4 threads. -Joe On Mar 25, 2014, at 2:21 PM, Ashish <[email protected]> wrote: > > > On Tuesday, March 25, 2014 11:30:42 PM UTC+5:30, Joe Love wrote: > Depending on your database, perhaps asynchronous query/response mechanisms? > I know PostgreSQL has "asynchronous command processing." I would imagine > quite a few databases libraries have something similar. > > -Joe > > > > Sorry this is leading me to more confusion. So, calling asynchronous DB > queries straight from event loop (through 'on_read') and not using threading > at all, is the recommended solution for my problem ? > > Well, the original problem is 'not being able to see any other callbacks than > on_read when there is DoS attack. > > > On Mar 25, 2014, at 12:54 PM, Ashish <[email protected]> wrote: > >> >> >> On Tuesday, March 25, 2014 4:53:09 PM UTC+5:30, Saúl Ibarra Corretgé wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> > >> >> Yes, I use uv_queue_work. I'll check with resources you've given. >> >> Many thanks :) But meanwhile any quick clue to get around this >> >> problem? >> > >> >> I don't think using uv_queue_work (in its current state) is a good >> idea. The threadpool just has 4 threads, and all file operations and >> getaddrinfo run there, so you'll saturate it pretty quickly. >> >> What processing do you do, which requires you to process it on a >> different thread? >> >> >> >> To process incoming requests I fire few DB queries and finally I send back >> response from 'after_thread' callback. Since its time consuming operation >> I've I threaded it off. >> (For some requests, I also call uv_async_send through thread to send some >> intermittent updates to requester client) >> >> If not uv_queue_work what are better options for me, please? >> >> Tnx, >> Ashish >> >> >> >> - -- >> Saúl Ibarra Corretgé >> bettercallsaghul.com >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> Comment: Using GnuPG with Icedove - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJTMWcdAAoJEEEOVVOum8BZWRYQAIN4g/BJGJYqGrzPU7B63XUt >> mIlkiAp2DLCFEiyjA4VdLHM/xmtNFWurxhSayOnvsGxk+4mhBc8xI+AxijMOPulp >> RVz7r3bfzTGCcj9dKh2y4f+GbqNkWhJpLqYLbCzPr/ojMYV0zISlxNi4Goylz19C >> 6mXqFxm7upD6yINRL0RuUGgEqyZSMgzsf96q+7TuboAa5TxDduEFvKxflgSHyAI1 >> +M2WN7iJLBVtRFGj0k69PxMnJBOmKpDu8mTQp/5fVLriTGvjMRM+XAoQiZMQVksq >> CxWQYD6x4x9B1/KJaSGlipEsRSedvtcW+iXYDU/eOHa5xnvcDPOJNcDWwsoPNBT9 >> +kMxLU49m8wQG2lT52GwwzCrRc1Iq61IArsiMFNa+5/kPOHJCwSmLtL1AYbVHeAC >> wyIYJvTP8ODtOsJi06aPf/LfHBvf1LD+UYUGH+ohzYf+Z9AdLBe5IV3a5ULid1zR >> GZaSbfo/Wnn0C4IJOjwbamhx5q0ysALPuq1xwTvQYdx7JVn8ArxghbBQdMUSflTP >> xmg31W6Ye3HALWg8I8Z5xVkGIXkUIDseP50EgGLyHbg4wQMc/Uf49LDXHsuIGJnM >> qYMZf9qGjvpdlA5zwCTvYDAcft2i51x6eaZDjG62hzn5+IR3ZKMJhcsHfgA110jm >> DJct0tclVMzDv2qsxzvq >> =/jcG >> -----END PGP SIGNATURE----- >> >> -- >> You received this message because you are subscribed to the Google Groups >> "libuv" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/libuv. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "libuv" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
