Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Any changes re dbases in upcoming RT products?

 [1/18] from: petr:krenzelok:trz:cz at: 2-Oct-2001 14:55


Hi, If not secret, I would like to know, if there are any changes introduced to upcoming RT products in database area? E.g. non-blocking ODBC, other drivers (PostGress, DB2), changes on FastCGI front (Holger? What was the conlusion of email exchange with Rob? Will there be any update to RTs own fast cgi solution?) Thanks, -pekr-

 [2/18] from: holger:rebol at: 2-Oct-2001 7:12


On Tue, Oct 02, 2001 at 02:55:16PM +0200, Petr Krenzelok wrote:
> Hi, > > If not secret, I would like to know, if there are any changes introduced > to upcoming RT products in database area? E.g. non-blocking ODBC,
Sterling might be able to answer that. Last I heard the Microsoft ODBC API was so inconsistent and buggy (no surprise, really, coming from Microsoft) that it is rather difficult to get it to work fully reliably at all across all versions and drivers. Adding non-blocking support would really be pushing it. I would like to see it, but it is probably not a priority any time soon.
> other > drivers (PostGress, DB2),
Direct support for PostgresSQL is planned. DB2: I don't know. I don't think we have had any requests.
> changes on FastCGI front (Holger? What was the > conlusion of email exchange with Rob? Will there be any update to RTs > own fast cgi solution?)
The conclusion was that REBOL's FastCGI handler has the same capabilities as all others (perl etc.), except that the inofficial Windows pipe hack is not supported. Considering how much trouble that hack has caused for applications that support it, not supporting it yet may be a Good Thing. I don't intend to make any functional changes at this time. REBOL FastCGI works well the way it is. Windows pipe support MAY be added later, if it becomes widely used and stable across Windows versions. -- Holger Kruse [holger--rebol--com]

 [3/18] from: koopmans:itr:ing:nl at: 2-Oct-2001 17:23


Is FastCGI non-blocking? Otherwise this is a performance thing: I don't want my FastCGI process to be blocking other requests to the same (external) instance. And FastCGI (at least in Apache and ZEUS) is dumb enough to only allow one external process on a URL (in stead of queueing and balancing it over multiple instance, like Xitami does with LRWP) In cases where you run it in external mode and manage it yourself you probably use the fastcgi REBOL as a load balancer for any number of application instances, but as data now comes from 'get-modes I don't see how to use it non-blocking.... Too me it feels useless for high-performance environments (100+ req/sec) but that's where you want FastCGI... I switched back to LRWP (thanks Robbert, do you want the changes?) --Maarten

 [4/18] from: holger:rebol at: 2-Oct-2001 9:17


On Tue, Oct 02, 2001 at 05:23:08PM +0200, Maarten Koopmans wrote:
> Is FastCGI non-blocking? Otherwise this is a performance thing: I don't want > my FastCGI process to be blocking other requests to the same (external) > instance. And FastCGI (at least in Apache and ZEUS) is dumb enough to only > allow one external process on a URL (in stead of queueing and balancing it > over multiple instance, like Xitami does with LRWP)
FastCGI supports /no-wait, but is otherwise blocking at the moment. Keep in mind that most people run the web server and the REBOL server on the same machine, so the setup part of FastCGI is virtually instantaneous (much less than 1 ms), because it does not depend on the web browser in any way, and the FastCGI protocol is asynchronous at a semantic level. Blocking writes are usually not a problem, at least not if the amount of data your program returns is less than about 16 kB, because in that case it is cached within socket buffers, so writing still appears as non-blocking to the application. -- Holger Kruse [holger--rebol--com]

 [5/18] from: sterling:rebol at: 2-Oct-2001 10:18


I'd like to get non-blocking support in there if possible. ODBC would be done first and the direct connections would most likely be done in later releases if they support it. There are additions like recording the number of affected rows, when appropriate, in the port which I'm planning on doing. Of course, any bugs and other features that have been submitted through feedback will be addressed as well. So if you have anything you really want to see happen, send it on in. :) Sterling

 [6/18] from: m:koopmans2:chello:nl at: 2-Oct-2001 19:53


I know... but I run a setup of 10 machines sandwitched between routers and firewalls. I will run at least 20 instances of the application. So.... But if times are below 1ms I should get somewhere with it. I'll push its limits ;-) --Maarten

 [7/18] from: petr:krenzelok:trz:cz at: 2-Oct-2001 20:26


----- Original Message ----- From: "Maarten Koopmans" <[koopmans--itr--ing--nl]> To: <[rebol-list--rebol--com]> Sent: Tuesday, October 02, 2001 5:23 PM Subject: [REBOL] Re: Any changes re dbases in upcoming RT products?
> Is FastCGI non-blocking? Otherwise this is a performance thing: I don't
want
> my FastCGI process to be blocking other requests to the same (external) > instance. And FastCGI (at least in Apache and ZEUS) is dumb enough to
only
> allow one external process on a URL
That's not true imo. Look at docs - with both static and dynamic configs you can use -processes X, where X is number of processes. Although it is a little bit static, you can allocate X processes for each URL imo. Other thing is, that Session Afinity patch is available for FastCGI, so it will do some kind of load balancing for you, or at least assign one session ID to the same process. Session afinity patch is coming to be default part of FastCGI distro, but we already know it will not help us, as RT uses own FastCGI implementation. Look also at FastCGIConfig directive - many options there ... I am stuck with Windows Apache version - Windows /Command allows usage of only External FastCGI server set-up. But pressing reload button on browser quickly two times crashes FastCGI listen loop. If I will not solve it, then I can regard FastCGI not being functional at all under Windows ... (in stead of queueing and balancing it
> over multiple instance, like Xitami does with LRWP) > > In cases where you run it in external mode and manage it yourself you > probably use the fastcgi REBOL as a load balancer for any number of > application instances, but as data now comes from 'get-modes I don't see
how
> to use it non-blocking.... > > Too me it feels useless for high-performance environments (100+ req/sec)
but
> that's where you want FastCGI... I switched back to LRWP (thanks Robbert,
do
> you want the changes?)
What is LRWP? Thanks, -pekr-

 [8/18] from: m:koopmans2:chello:nl at: 2-Oct-2001 20:37


mod_fastcgi docs?

 [9/18] from: holger:rebol at: 2-Oct-2001 11:49


On Tue, Oct 02, 2001 at 08:26:56PM +0200, Petr Krenzelok wrote:
> That's not true imo. Look at docs - with both static and dynamic configs you > can use -processes X, where X is number of processes. Although it is a
<<quoted lines omitted: 4>>
> FastCGI distro, but we already know it will not help us, as RT uses own > FastCGI implementation.
I would assume such a patch to affect the web server only, so it would work with REBOL in the same way as with other programs.
> I am stuck with Windows Apache version - Windows /Command allows usage of > only External FastCGI server set-up. But pressing reload button on browser > quickly two times crashes FastCGI listen loop. If I will not solve it, then > I can regard FastCGI not being functional at all under Windows ...
Crashes how ? -- Holger Kruse [holger--rebol--com]

 [10/18] from: m::koopmans2::chello::nl at: 2-Oct-2001 20:41


LRWP: Long Running Web Processes, the Xitami only FastCGI like protocol. Extremely simple to implement: XItami post zerofilled 9 byte env length, env , zero-filled 9byte post length , post params. You give back zero-filled 9 byte content length, content. You assign a LRWP to a URL, if it is not there, the default action is performed, so if I assign an LRWP to test.html, test.html is displayed if there are no processes, which is a very graceful exit. LRWP processes connect to the server for a certain LRWP url, and if more than one connect for the same URL Xitami queues and balances. It is very neat. Robbert did some preliminary lrwp code, that I adjusted to correctly handle posts as well. It performs *very* good. --Maarten

 [11/18] from: petr:krenzelok:trz:cz at: 2-Oct-2001 21:14


----- Original Message ----- From: <[holger--rebol--com]> To: <[rebol-list--rebol--com]> Sent: Tuesday, October 02, 2001 8:49 PM Subject: [REBOL] Re: Any changes re dbases in upcoming RT products?
> On Tue, Oct 02, 2001 at 08:26:56PM +0200, Petr Krenzelok wrote: > > That's not true imo. Look at docs - with both static and dynamic configs
you
> > can use -processes X, where X is number of processes. Although it is a > > little bit static, you can allocate X processes for each URL imo. Other > > thing is, that Session Afinity patch is available for FastCGI, so it
will do
> > some kind of load balancing for you, or at least assign one session ID
to
> > the same process. Session afinity patch is coming to be default part of > > FastCGI distro, but we already know it will not help us, as RT uses own > > FastCGI implementation. > > I would assume such a patch to affect the web server only, so it would > work with REBOL in the same way as with other programs. > > > I am stuck with Windows Apache version - Windows /Command allows usage
of
> > only External FastCGI server set-up. But pressing reload button on
browser
> > quickly two times crashes FastCGI listen loop. If I will not solve it,
then
> > I can regard FastCGI not being functional at all under Windows ... > > Crashes how ?
I already reported it to feedback some time ago and also asked for participation of folks here on ml. No response though. So - I use simple loop found in your FastCGI docs. I parse out requested html file and do it, e.g.: http://my.domain.com/fcgi-bin/invoices.fcgi so the code results in do %invoices.fcgi ... where I look if ODBC connection is already set-up, and if not, I do open one. Then I do some select, taking some time ... If I do everything in sequential manner, e.g. in rebol console: read http://my.domain.com/fcgi-bin/invoices.fcgi, everything is OK, - Rebol handles for me 3 rather complex queries per second. It is 34 kb of data per request. But - once I press reload button two times quickly, main FastCGI loop crashes on strange timeout bug ... I assume some user can double click on reload and I've got a problem ... Any hints here? I tried it on Win2K Apach External FastCGI set-up. Thanks, -pekr-

 [12/18] from: holger:rebol at: 2-Oct-2001 13:14


On Tue, Oct 02, 2001 at 09:14:50PM +0200, Petr Krenzelok wrote:
> If I do everything in sequential manner, e.g. in rebol console: read > http://my.domain.com/fcgi-bin/invoices.fcgi, everything is OK, - Rebol > handles for me 3 rather complex queries per second. It is 34 kb of data per > request. But - once I press reload button two times quickly, main FastCGI > loop crashes on strange timeout bug
That's my point. "strange timeout bug" is not very informative. In order to track this one down we would need the exact error, your environment etc. Have you tried it with the Win32 REBOL binary and a Linux Apache version (connecting from Linux to Win32) ? That would help... -- Holger Kruse [holger--rebol--com]

 [13/18] from: petr:krenzelok:trz:cz at: 3-Oct-2001 0:50


----- Original Message ----- From: <[holger--rebol--com]> To: <[rebol-list--rebol--com]> Sent: Tuesday, October 02, 2001 10:14 PM Subject: [REBOL] Re: Any changes re dbases in upcoming RT products?
> On Tue, Oct 02, 2001 at 09:14:50PM +0200, Petr Krenzelok wrote: > > > If I do everything in sequential manner, e.g. in rebol console: read > > http://my.domain.com/fcgi-bin/invoices.fcgi, everything is OK, - Rebol > > handles for me 3 rather complex queries per second. It is 34 kb of data
per
> > request. But - once I press reload button two times quickly, main
FastCGI
> > loop crashes on strange timeout bug > > That's my point. "strange timeout bug" is not very informative. In order > to track this one down we would need the exact error, your environment > etc.
Well, OK. IIRC I sent it to this ml some time ago, as well as to feedback, as well as to Express conference. I will try to find/reproduce it tomorrow at my work, and will send you even rather short script ...
> Have you tried it with the Win32 REBOL binary and a Linux Apache > version (connecting from Linux to Win32) ? That would help...
W2K OS, W2K Apache, localhost config, everything on one machine .... OK, I found conference message: ---------------------- who: "petr.krenzelok_trz.cz" when: 2-Sep-2001/2:40:55-7:00 color: 26.35.243 content: {What is more - the only one mode of FastCGI, which seems to work under Windows, is FastCGIExternalServer directive. But - pressing immediatelly reload button on Internet Explorer causes rebol script to crash: ** Access Error: Network timeout ** where emitX , where emitX is simple function, containing [insert conn-port head buffer clear buffer], where buffer is my string I append db query results to, before I decide going to output. It seems to me like during fast reload of browser, Rebol catches somehow new request before old one is finished, and does something with conn-port, so old request can't insert data into it anymore. But logic of the script is against it - no multiplexing over ports is used, so I have suspicion that /Command has broken asynchronicity in regards to serving external (browser) side of requests .. Maybe Holger or Sterling could answer this one here? Because in current state, FastCGI is not usable under Windows at all.} group: "Support" --------------------------- -pekr-

 [14/18] from: dockimbel:free at: 3-Oct-2001 1:27


Hi Petr, Petr Krenzelok wrote: [...]
> Other > thing is, that Session Afinity patch is available for FastCGI, so it will do > some kind of load balancing for you, or at least assign one session ID to > the same process. Session afinity patch is coming to be default part of > FastCGI distro, but we already know it will not help us, as RT uses own > FastCGI implementation.
AFAIK, Session Affinity patch is applied on mod_fastcgi.c and as you explained, allow to associate a session ID to an application instance in order to pass all requests of a given user to the same instance. This way you don't have to save/reload contexts from one app instance to another. With the SA patch, it can be easier to design your apps and they will perform a little bit faster (speed gain depends on contexts saving/reloading time). IIRC, SA patch has nothing to do with the FastCGI protocol, so it will work with any kind of app including of course, /Command. Regards, DocKimbel.

 [15/18] from: ljurado:bariloche:ar at: 2-Oct-2001 20:44


Maarten: Is your LRWP code public ? Luis.

 [16/18] from: m:koopmans2:chello:nl at: 3-Oct-2001 10:37


It will be if you want it to? I am out of the office now, but I'll send it to the REB one of these days and post it. --Maarten

 [17/18] from: robert:muench:robertmuench at: 3-Oct-2001 22:11


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 5>>
> that's where you want FastCGI... I switched back to LRWP (thanks Robert, do > you want the changes?)
Hi, oh yes please, I didn't updated the code to new versions a long time and IMO Xitamis LRWP is much cooler than FastCGI ;-)). Robert

 [18/18] from: petr:krenzelok:trz:cz at: 3-Oct-2001 22:28


----- Original Message ----- From: "Robert M. Muench" <[robert--muench--robertmuench--de]> To: <[rebol-list--rebol--com]> Sent: Wednesday, October 03, 2001 10:11 PM Subject: [REBOL] Re: Any changes re dbases in upcoming RT products?
> > -----Original Message----- > > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 3>>
> > Subject: [REBOL] Re: Any changes re dbases in upcoming RT products? > > Too me it feels useless for high-performance environments (100+ req/sec)
but
> > that's where you want FastCGI... I switched back to LRWP (thanks Robert,
do
> > you want the changes?) > > Hi, oh yes please, I didn't updated the code to new versions a long time
and IMO
> Xitamis LRWP is much cooler than FastCGI ;-)). Robert
But that's it - Xitami - we support Indians :-) Apache :-) -pekr-

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted