Nice! On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote:
> Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > On Thursday, June 14, 2012 5:08:15 AM UTC+1, darren wrote: > > Not sure if this will help, Oren, but it shows a very (very!) simple way > of passing commands to a long-running python shell from node using a > command queue. You might be able to try a similar thing. > https://github.com/darrenderidder/node-python/blob/master/lib/python.js > > Darren > > On Wednesday, June 13, 2012 10:49:32 AM UTC-4, Oren ZBM wrote: >> >> Hi all, >> >> I wonder what is the king's road for implementing the following. >> >> Web/API server receiving many requests, all need to be handled by yet >> another process, so some distributed queue, or just TCP/IP mechanism >> should be used. When the other process is done and the reply returns >> to node.js . How to "wake" the right context (callback) and return the >> result to the right client? >> >> I guess mongodb driver is doing something similar, even if I use the >> same driver object, still every concurrent HTTP request gets its own >> results sets (from mongodb) for its own query. >> >> My brute force idea is to create temporary queues for single use, per >> request/reply. One queue for requests, in which each item will be the >> request, and the id of the temporary reply queue. This shoukd work, >> yet I have a feeling there is a better way. >> >> I may end up looking at mongodb driver's implementation... >> >> >> With kind regards, >> Oren >> -- > > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
