Re: Ax2: contributing
On 24 Jan 2007 at 11:39, Also Sprach Matt Sergeant: On 24-Jan-07, at 10:52 AM, [EMAIL PROTECTED] wrote: Given the above (I presume it's correct) the ways around it are 1) Have a separate DBI daemon that processes requests and uses Danga. In the next release I hope to build a job server for long running things. Ha! when's the next release? :) Not sure how feasible it is, but we'll give it a go. Will it be another ax2 server that essentially does RPC from the main server? Something along the lines of using Danga to listen on a FD (as per the Ax2 docs)? The methods on the main ax2 server then have to have some CONTINUATION jiggery pokery? John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ax2: contributing
On Thursday, 25. January 2007 11:10, [EMAIL PROTECTED] wrote: On 24 Jan 2007 at 11:39, Also Sprach Matt Sergeant: On 24-Jan-07, at 10:52 AM, [EMAIL PROTECTED] wrote: Given the above (I presume it's correct) the ways around it are 1) Have a separate DBI daemon that processes requests and uses Danga. In the next release I hope to build a job server for long running things. Ha! when's the next release? :) Not sure how feasible it is, but we'll give it a go. Will it be another ax2 server that essentially does RPC from the main server? Something along the lines of using Danga to listen on a FD (as per the Ax2 docs)? The methods on the main ax2 server then have to have some CONTINUATION jiggery pokery? I guess there will be no way around that part, no matter how you do it. I have been working on a cool solution to that, but for now I still don't know if it will actually work out in a way that is useful. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ax2: contributing
On 25-Jan-07, at 5:10 AM, [EMAIL PROTECTED] wrote: Not sure how feasible it is, but we'll give it a go. Will it be another ax2 server that essentially does RPC from the main server? Something along the lines of using Danga to listen on a FD (as per the Ax2 docs)? The methods on the main ax2 server then have to have some CONTINUATION jiggery pokery? Something like that. Hopefully hidden behind a nice API. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ax2: contributing
On Wed, Jan 24, 2007 at 03:51:45PM +0100, J?rg Walter wrote: On Wednesday, 24. January 2007 13:29, [EMAIL PROTECTED] wrote: I was wondering if it would be possible to contribute to the project a mysql db app? They don't come more dynamic than a db app :) Did you solve the problem of asynchronous queries? I think that was the main problem last time. You can't do DB queries like you use to do them in mod_perl, because the process may be blocked for several seconds on complex queries. And blocking AxKit2 means _nothing_ is served in that time. The MySQL client library is crap in this regard. The pgsql client (and protocol) is based on asynchronous message passing, and it's extremely easy to multiplex SQL statements. I've done this in several single-threaded Perl applicatoins useing libevent/Event::Lib. For MySQL (and any other difficult database), you'd ideally use a thread pool, or more likely a process pool. The latter case sucks, because then you basically have to reinvent another SQL client protocol. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ax2: contributing
On Wednesday, 24. January 2007 13:29, [EMAIL PROTECTED] wrote: I was wondering if it would be possible to contribute to the project a mysql db app? They don't come more dynamic than a db app :) Did you solve the problem of asynchronous queries? I think that was the main problem last time. You can't do DB queries like you use to do them in mod_perl, because the process may be blocked for several seconds on complex queries. And blocking AxKit2 means _nothing_ is served in that time. -- CU Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ax2: contributing
On 24 Jan 2007 at 15:51, Also Sprach Jörg Walter: On Wednesday, 24. January 2007 13:29, [EMAIL PROTECTED] wrote: I was wondering if it would be possible to contribute to the project a mysql db app? They don't come more dynamic than a db app :) Did you solve the problem of asynchronous queries? No. I have no idea how to go about it. I don't believe it could be done from the application, it would involve some hairy stuff in the DBI, if it's possible at all. I just have to content myself with not writing crappy sql :) A page typically takes 100th of a second to generate on our production server, which isn't too shabby. Given the above (I presume it's correct) the ways around it are 1) Have a separate DBI daemon that processes requests and uses Danga. ie A db request is palmed off to the DBI server and the DBI server gives Ax2 a kick when the data has been retrieved. I believe Danga sockets have this capability. 2) Have Ax2 forkable. qpsmtpd which seems very similar to this has a qpsmtpd-forkserver option. This may or may not be possible with Ax2 3) Go back to Ax1 and apache. John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ax2: contributing
On 24-Jan-07, at 10:52 AM, [EMAIL PROTECTED] wrote: Given the above (I presume it's correct) the ways around it are 1) Have a separate DBI daemon that processes requests and uses Danga. ie A db request is palmed off to the DBI server and the DBI server gives Ax2 a kick when the data has been retrieved. I believe Danga sockets have this capability. In the next release I hope to build a job server for long running things. Not sure how feasible it is, but we'll give it a go. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
