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