You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/02/03 16:57:17 UTC
[OT rant] there must be some way out of here...
...there's too much confusion here, I can't get no relief.
Besides quoting Bob Dylan, I'm *PISSED OFF* since I've spent the entire
day trying to get Apache 2.0.x + Tomcat *.* working on Solaris and I
decided to throw everything down the drain.
I'll never use Tomcat again. Period. The phylosophy behind it (big
servlet engine, light http stack on top) is plain wrong.
mod_jserv is not supported anymore. :(
mod_jk is piece of [insert your favorite nasty word here] (who is the
genious that invented the concept that the servlet engine should
generate the configuration file for the web server module?).
mod_jk2 is even worse (who invented its configuration format must think
in sanscrit and never heard of virtual hosts).
mod_webapp (which is the only *human* one) is dead.
Tomcat is getting bigger and slower every day and must do only one
stupid thing (connect a URI to a servlet, dah!) that we were able to do
in jserv with some 120Kb of java code. Talking about flexibility
syndrome. Hello? we already have a damn good web server!!! just because
you can't configure it doesn't mean you have to rewrite one from
scratch. get a life.
Its connectors win the nobel price for cryptic configuration files and
absent documentation (the first who says that cocoon docs sucks will
have to figure out how to compile tomcat and connectors from source
before being allowed to speak again)
Moreover, there are *three* different tomcat implementations
concurrently maintained.
I'm sick of this.
And I'm not alone.
Enough talking, expect action.
Soon.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine neccesitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Stefano Mazzocchi <st...@apache.org>.
Miles Elam wrote:
> So let me see if I'm understanding now. You aren't angry because Tomcat
> has its own HTTP stack. You are angry because they seem to be going out
> of their way to keep other HTTP stacks from working with it.
Close.
I'm angry because Tomcat people *fail* to see that no matter how hard
you try, java is not a solution for mission critical httpd stacks. This
is not the usual anti-java religion and might come from a unix sysadm,
it's the light seen after reaching java's metal.
I'm not against a servlet engine having an HTTP stack (we were working
on adding one to jserv right before tomcat was donated), but I'm angry
at the Tomcat community where focus has shifted from industrial quality
servlet engines (as it was jserv) to accademic bloated R&D and
implementing features (think valves) that nobody ever asked for.
God how much I miss jserv :(
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wednesday, Feb 5, 2003, at 21:45 Europe/London, Miles Elam wrote:
> Pier answered my question with a lot of great information such as
> multi-process robustness, fall-back error pages when/if a JVM goes
> down, etc. However, I noticed one hole in the setup he proposed: URI
> permanence. You'll note that he created a "/static/" mapping for
> content that Apache should serve raw instead of passing the request to
> a servlet engine. What does "/static/" do but tie your implementation
> to your URI -- precisely the type of thing Cocoon 2 was made to avoid.
> What does the fact that I have a picture of a train crossing have to
> do with "/static/images/traincrossing.jpg"? I might as well have a
> URI like "/images.php?name=traincrossing".
You've got this all wrong. Apache has much better support for URL
permanence than you're giving it credit for. This is why the AxKit
project hasn't felt the need to implement a full blown sitemap -
because Apache does it for us.
> When it comes down to it, I'm trying to wrap my head around an optimum
> solution and not the optimum solution with HTTPd, Tomcat, or even
> Java. If HTTPd (with its robustness) had an expressive sitemap, I
> would be singing in the streets right now.
It does - you just haven't looked into it (or maybe its not very well
documented. Either way that doesn't mean its not there).
Matt.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Miles Elam <mi...@pcextremist.com>.
Stefano Mazzocchi wrote:
>> And handle servlet filters and implement the HTTP 1.1 spec in
>> totality, right?
>>
>> As far as HTTPd is concerned, it's a web
>> server...er...proxy...er...connection hub...er...
>
>
> no, it's a rock-solid HTTP stack with modular capabilities. It's up to
> you on what modules you add. From an architectural perspective HTTPd
> is a framework for HTTP-based functionality.
And this is what you see for servlet engines I assume: a servlet API to
HTTP framework? The fact of the matter is that the Tomcat developers
are doing much the same thing that Apache did when they split off from
the CERN server, right? Are you sure that your love of HTTPd isn't
biasing your argument just a little? I understand that this is a rant,
but still...
Is your main criticism that JSP functionality isn't pluggable?
(Although it is if you remove jasper.jar and any reference to Jasper and
JSPs in the config files.)
I guess I'm the only one who doesn't think that HTTPd's config files are
all that clear. If it weren't for the comments, I'd be completely lost
sometimes -- or at least as much or more than the first time I saw
Tomcat's configuration files. Please don't forget that you've had YEARS
to get familiar with HTTPd.
(And no, I'm not arguing that HTTPd is bad. That would be a fool's
cause. But some of the fire and brimstone smells a bit like code religion.)
>> The one thing I miss about having Apache in front of my servlet
>> engine (I currently run with Tomcat bare) is the reliability
>> associated with forking and recycling child processes. Honestly, if
>> Cocoon is already demonstrating that PHP and Perl (directly
>> generating HTML) are suboptimal methods for creating sites on a large
>> scale, why use HTTPd at all?
>
>
> because cocoon simply produces the content and somebody else does the
> transport.
>
> SoC.
I'm afraid you misunderstood my statement. I only brought up PHP and
Perl as examples of some of the most-used modules in HTTPd. I'm not
suggesting that Cocoon should listen on port 80. In my case, Cocoon is
the content and Tomcat is the transport. My question was that if Tomcat
(or Jetty, Resin, etc.) is acting as the transport and the site is based
upon technologies covered by Cocoon and/or other servlets, what
important role does HTTPd play?
Pier answered my question with a lot of great information such as
multi-process robustness, fall-back error pages when/if a JVM goes down,
etc. However, I noticed one hole in the setup he proposed: URI
permanence. You'll note that he created a "/static/" mapping for
content that Apache should serve raw instead of passing the request to a
servlet engine. What does "/static/" do but tie your implementation to
your URI -- precisely the type of thing Cocoon 2 was made to avoid.
What does the fact that I have a picture of a train crossing have to do
with "/static/images/traincrossing.jpg"? I might as well have a URI
like "/images.php?name=traincrossing".
When it comes down to it, I'm trying to wrap my head around an optimum
solution and not the optimum solution with HTTPd, Tomcat, or even Java.
If HTTPd (with its robustness) had an expressive sitemap, I would be
singing in the streets right now. The conversations about having
non-blocking I/O bit blast the Cocoon cache to the output stream really
got my gears turning, but that still misses HTTPd's robustness. In the
end, I'm stuck looking at HTTPd doing nothing except pump requests to
multiple backend JVMs, and that just seems "good enough" instead of
"good" to me.
> I never advocated the use of *all* httpd modules to connect to cocoon.
> What I advocate is that *ONE* HTTP stack is good enough and we just
> need a thin HTTPd->java layer to connect our cocoon to it and tomcat
> is not thin at all!
This is predicated on the assumption that HTTPd is necessary! Do you
understand that you are ensuring that HTTPd be part of the equation and
not looking from first principles. I'm not saying you're wrong. I'm
asking you to stay objective. You are advocating a servlet engine
without any web serving capability because you have already decided that
HTTPd *must be* the HTTP stack.
> Jserv was built by people who wanted to add java to the http world.
> Tomcat is built by people who want to add http to the java world.
>
> See my problem?
Yes, but the same statement could be written as:
Jserv was built by people who wanted to add servlets to C. Tomcat is
built be people who wanted to allow access to servlets from C.
Having putzed around with the Apache module API, ISAPI, NSAPI, and the
servlet API, I can see both points of view. Compared to the others, the
servlet API is so simple, so easy to use, so intuitive that it's painful
to even consider the others. Some of it is the Java language (and the
fact that C doesn't have true objects). I don't presume to say that the
servlet API is perfectly clean -- I don't believe myself to be all that
delusional -- but it's a damn sight better than most alternatives.
HTTPd is *very* C-centric in much the same way that Tomcat is
Java-centric. Yes, there are C++ "wrappers" for modules, but this is an
ad hoc addition that isn't codified or standardized at all. Everything
but C is a second (or third) class citizen. Perl? Ask the folks who
have been waiting for a stable mod_perl for HTTPd 2.0.
>> Okay, compiling that beast, I'll have to agree. But aside from
>> connecting Tomcat to HTTPd, I haven't really found it to be an issue
>> -- especially with the work done to make a web-based management console.
>
>
> there was mod_jserv. it was hard to configure, but we wrote docs and
> people were happy.
>
> then came mod_jk and WARs, configurations became a pain and instead of
> writing docs, they decided to have tomcat autogenerate the
> configurations for the module. (can you see the tomcat-centricity on
> this?)
Ah. Okay. Now I'm getting it. This is an area I've avoided because I
haven't been using HTTPd, but it's a valid point nonetheless. Tie-in is
tie-in. You want the work done to connect HTTPd to a servlet engine to
be unified and a single point of development instead of Resin's
connector, Jetty's connector, Tomcat's connector, etc.
> The anger comes from the fact that all technological decisions in
> tomcat ruined the work several of us have done over years. And none of
> us (even working inside sun, as Pier) had the energy to fight stupid
> moves.
I remember the clustering docs from the JServ days, but never followed
up on them in later years (my company went to a non-servlet solution).
So let me see if I'm understanding now. You aren't angry because Tomcat
has its own HTTP stack. You are angry because they seem to be going out
of their way to keep other HTTP stacks from working with it. If this is
the case, you've got me convinced.
>> On another note: does anyone see a future in using something like gcj
>> to more closely link a servlet engine to Apache HTTPd to regain the
>> stability areas I mentioned earlier and to avoid the socket
>> communications? The only thing that pops out in my head is Batik as gcj
>> doesn't have the graphics APIs down yet.
>
>
> that's not the problem. the problem is interface-based dynamic loading
> of our Component-oriented programming paradigms. Something that gcj
> folks probably don't even know it exists. [I'd be happy to be proven
> wrong, though]
gcj has dynamic classloading and a linkable interpreter. I know that
Tomcat has been successfully compiled to native code with gcj.
Considering the comments regarding difficulty in compiling Tomcat at
all, this has got to be worth something.
Looking at the status page (http://gcc.gnu.org/java/status.html), the
items that stick out as missing are not related to interfaces, but
rather graphics handling (affects Batik), directory access (affects
calls to J2EE), and java.text (which would hinder the i18n work). Since
I've been casually following the gcj project, I've noticed that
interfaces have been a major focus at times.
> Hope this gives you more information.
Indeed! And I'll go check out the avalon-dev archives for more info on
the JNDI discussion.
- Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Stefano Mazzocchi <st...@apache.org>.
Miles Elam wrote:
> Stefano Mazzocchi wrote:
>
>> I'll never use Tomcat again. Period. The phylosophy behind it (big
>> servlet engine, light http stack on top) is plain wrong.
>
>
>
> I'm confused... One of the features of the newest iterations of Tomcat
> is jndi lookups without the whole of EJB behind it. Data sources,
> variables, et al. in a standard (for Java) interface. How is having
> Cocoon handle it (through Avalon by proxy) better than having the engine
> handle it?
Tomcat was sold to us JServ developers as the Servlet 2.1 reference
implementation for the servlet API. Then, they started sneaking JSP into
that (did you notice that you get JSPs for tomcat even if you don't want
them nor use them?), now they start sneaking JNDI in? what if I don't care?
My point is: the servlet API is a *very* simple API, every servlet
engine which is bigger than 100Kb in size is doing something wrong.
Avalon is a server framework. Tomcat should be the servlet engine, the
JNDI datasource should be another avalon block and both will cooperate.
But the tomcat development community believes there is only one way of
doing things, Sun's. I'm sick of this and almost *all* others who made
the Servlet API a reality.
> This actually brings up another question as I could not find the answer
> in the archives. What does the Avalon component manager buy us that a
> jndi lookup cannot considering the easier migration path from one simple
> jndi lookup implementation to a more advanced (J2EE-backed) jndi lookup
> implementation without mucking with too much underlying code (they are
> all components, right?).
>
> Not trying to start a fight. I'm honestly curious.
In Avalon-dev there are *tons* of email discussions about why JNDI was
not capable enough for what Avalon was trying to do. Berin, do you have
pointers to those discussions?
>> Tomcat is getting bigger and slower every day and must do only one
>> stupid thing (connect a URI to a servlet, dah!) that we were able to
>> do in jserv with some 120Kb of java code. Talking about flexibility
>> syndrome. Hello? we already have a damn good web server!!! just
>> because you can't configure it doesn't mean you have to rewrite one
>> from scratch. get a life.
>
>
>
> And handle servlet filters and implement the HTTP 1.1 spec in totality,
> right?
>
> As far as HTTPd is concerned, it's a web
> server...er...proxy...er...connection hub...er...
no, it's a rock-solid HTTP stack with modular capabilities. It's up to
you on what modules you add. From an architectural perspective HTTPd is
a framework for HTTP-based functionality.
> The one thing I miss
> about having Apache in front of my servlet engine (I currently run with
> Tomcat bare) is the reliability associated with forking and recycling
> child processes. Honestly, if Cocoon is already demonstrating that PHP
> and Perl (directly generating HTML) are suboptimal methods for creating
> sites on a large scale, why use HTTPd at all?
because cocoon simply produces the content and somebody else does the
transport.
SoC.
> mod_gzip? Is it really
> so much more efficient than a compression servlet filter?
who cares, this is not the point.
> Is it really
> more efficient that a filter could be? mod_speling? Doesn't that start
> to fail when the files aren't static? How would you map this to the
> sitemap?
I never advocated the use of *all* httpd modules to connect to cocoon.
What I advocate is that *ONE* HTTP stack is good enough and we just need
a thin HTTPd->java layer to connect our cocoon to it and tomcat is not
thin at all!
> It can't be web serving speed with the non-blocking I/O available in
> Java 1.4.
no it's not speed, damn it. Who cares about http speed if your stinking
database is taking two seconds to execute a query?
It's about community, support, talent of thousands who worked on it.
Java infected people with the concept that WORA equals "pure java"
equals "reinvent the wheel everytime".
And tomcat is build on top of that concept!
Jserv was built by people who wanted to add java to the http world.
Tomcat is built by people who want to add http to the java world.
See my problem?
>> Its connectors win the nobel price for cryptic configuration files and
>> absent documentation (the first who says that cocoon docs sucks will
>> have to figure out how to compile tomcat and connectors from source
>> before being allowed to speak again)
>
>
>
> Okay, compiling that beast, I'll have to agree. But aside from
> connecting Tomcat to HTTPd, I haven't really found it to be an issue --
> especially with the work done to make a web-based management console.
there was mod_jserv. it was hard to configure, but we wrote docs and
people were happy.
then came mod_jk and WARs, configurations became a pain and instead of
writing docs, they decided to have tomcat autogenerate the
configurations for the module. (can you see the tomcat-centricity on this?)
> I am honestly confused. I have no affiliation with the Tomcat team
> except for filing a bug once. Private mail or public is fine for a
> response, but I am somewhat at a loss for all this anger.
The anger comes from the fact that all technological decisions in tomcat
ruined the work several of us have done over years. And none of us (even
working inside sun, as Pier) had the energy to fight stupid moves.
> On another note: does anyone see a future in using something like gcj to
> more closely link a servlet engine to Apache HTTPd to regain the
> stability areas I mentioned earlier and to avoid the socket
> communications? The only thing that pops out in my head is Batik as gcj
> doesn't have the graphics APIs down yet.
that's not the problem. the problem is interface-based dynamic loading
of our Component-oriented programming paradigms. Something that gcj
folks probably don't even know it exists. [I'd be happy to be proven
wrong, though]
> Once again, not trying to start a fight. I honestly would like to know.
Hope this gives you more information.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine neccesitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 4/2/03 23:06, "Miles Elam" <mi...@pcextremist.com> wrote:
>
> Honestly, if Cocoon is already demonstrating that PHP
> and Perl (directly generating HTML) are suboptimal methods for creating
> sites on a large scale, why use HTTPd at all? mod_gzip? Is it really
> so much more efficient than a compression servlet filter? Is it really
> more efficient that a filter could be? mod_speling? Doesn't that start
> to fail when the files aren't static? How would you map this to the
> sitemap?
Burn the heretic! Burn the heretic! Burn the heretic! :-) :-) :-)
Kidding, of course... No, all that you wrote is indeed not a great
advantage. Actually, I never used mod_gzip (which is, yes, faster than a
servlet filter just by matter of buffering stuff at a native level rather
than in a VM - we're talking about probably a 4/5% max, though) or
mod_speWHAT? :-)
At VNU we use Apache as a "switchboard" basically, our front-end to our
customers: we know it's reliable, we know it's always there, we know it that
when its configured correctly it allows us to play some tricks that we could
forget when using Tomcat (or whatever servlet container) alone... It's
"flexible"...
It's like our receptionist, our front-end to our customers: she's reliable,
she's always there, and if you tell her things in the right way, she can
even plan your next meeting when you're out of the office sick (or she can
play the trick of telling you're sick when you simply don't want to talk to
that person)...
Seriously, after 6 years of daily use, I wouldn't be able to get the same
results I get out of Apache out of any other HTTP stack available on this
planet, simply because they're not _there_ yet! :-)
> Okay, compiling that beast, I'll have to agree. But aside from
> connecting Tomcat to HTTPd, I haven't really found it to be an issue --
> especially with the work done to make a web-based management console.
Oh, yes, forgot to say that Stefano was trying to install Tomcat on one of
my machines, an he knows that if he installs an "admin tool" he's going to
see his root privileges removed on the spot...
Yes, indeed, admin tools could be all-right, but my philosophy is don't rely
on them, otherwise when you're in troubles, you don't really have a clue on
where to put your hands. _Know_ what you're doing first, then make it easier
if it's a repetitive and stupid task, and remember that one day it will
happen that all you got left on your server is only a VT-100 serial
connection at 9600 BPS...
Connecting a servlet container with an HTTP server is something you should
know in every possible little minimal detail, because (at least this is true
in my case) your web-serving life relies on it.
> On another note: does anyone see a future in using something like gcj to
> more closely link a servlet engine to Apache HTTPd to regain the
> stability areas I mentioned earlier and to avoid the socket
> communications? The only thing that pops out in my head is Batik as gcj
> doesn't have the graphics APIs down yet.
I believe, and I enjoyed the fact, that the Cocoon team is moving into one
clear direction: having the _best_ XML-based serving platform available on
the planet.
I _love_ the choice of having an interpreted sitemap, for example, or the
Javascript-based flow/continuations. The use of Avalon blocks is another...
Cocoon is not only the best (IMO) but as well the more _elegant_ solution
from a design point of view (it might not be _there_ yet, but I see all of
the folks who made this project great in the past few years going towards
the same goal).
Performances? All right, that's where the whole elegance comes into play.
Cocoon relies on Components, and in a beautiful separation-of-concerns
manner, it relies on individual components to be the most performant
components possible... Cocoon is the glue that ties together all those...
And if you ask me about the specific performance of the HTTP stack, don't
worry, there will be a day in which someone will come up with a solution to
tie one of the most optimized HTTP stack on this planet (Apache 2) and our
Cocoon glue in the fastest (and simplest) way possible...
It _will_ happen, I'm just waiting for Stefano to move to London so that he
can beat the crap out of me and make me work :-) :-)
My goal (and what I'm paid for) is to use Cocoon on a site that generates
roughly 0.5 millions hits per hour, and, yes, the baby can do it, easy! :-)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Miles Elam <mi...@pcextremist.com>.
Stefano Mazzocchi wrote:
> I'll never use Tomcat again. Period. The phylosophy behind it (big
> servlet engine, light http stack on top) is plain wrong.
I'm confused... One of the features of the newest iterations of Tomcat
is jndi lookups without the whole of EJB behind it. Data sources,
variables, et al. in a standard (for Java) interface. How is having
Cocoon handle it (through Avalon by proxy) better than having the engine
handle it?
This actually brings up another question as I could not find the answer
in the archives. What does the Avalon component manager buy us that a
jndi lookup cannot considering the easier migration path from one simple
jndi lookup implementation to a more advanced (J2EE-backed) jndi lookup
implementation without mucking with too much underlying code (they are
all components, right?).
Not trying to start a fight. I'm honestly curious.
> Tomcat is getting bigger and slower every day and must do only one
> stupid thing (connect a URI to a servlet, dah!) that we were able to
> do in jserv with some 120Kb of java code. Talking about flexibility
> syndrome. Hello? we already have a damn good web server!!! just
> because you can't configure it doesn't mean you have to rewrite one
> from scratch. get a life.
And handle servlet filters and implement the HTTP 1.1 spec in totality,
right?
As far as HTTPd is concerned, it's a web
server...er...proxy...er...connection hub...er... The one thing I miss
about having Apache in front of my servlet engine (I currently run with
Tomcat bare) is the reliability associated with forking and recycling
child processes. Honestly, if Cocoon is already demonstrating that PHP
and Perl (directly generating HTML) are suboptimal methods for creating
sites on a large scale, why use HTTPd at all? mod_gzip? Is it really
so much more efficient than a compression servlet filter? Is it really
more efficient that a filter could be? mod_speling? Doesn't that start
to fail when the files aren't static? How would you map this to the
sitemap?
It can't be web serving speed with the non-blocking I/O available in
Java 1.4.
> Its connectors win the nobel price for cryptic configuration files and
> absent documentation (the first who says that cocoon docs sucks will
> have to figure out how to compile tomcat and connectors from source
> before being allowed to speak again)
Okay, compiling that beast, I'll have to agree. But aside from
connecting Tomcat to HTTPd, I haven't really found it to be an issue --
especially with the work done to make a web-based management console.
I am honestly confused. I have no affiliation with the Tomcat team
except for filing a bug once. Private mail or public is fine for a
response, but I am somewhat at a loss for all this anger.
On another note: does anyone see a future in using something like gcj to
more closely link a servlet engine to Apache HTTPd to regain the
stability areas I mentioned earlier and to avoid the socket
communications? The only thing that pops out in my head is Batik as gcj
doesn't have the graphics APIs down yet.
Once again, not trying to start a fight. I honestly would like to know.
- Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Berin Loritsch" <bl...@apache.org> wrote:
>
> The Haboob server built on SEDA has promise--although it is primarily a
> research project. Imagine being able to gracefully handle 10,000
> clients simultaneously with a proper scaling of performance--all in
> Java. (it makes use of the NBIO library with JNI). It is no where
> near Servlet compliant, but as a static HTML or simple CGI based server
> that is impressive by any standard.
>
> In fact this server outperformed Apache HTTPD 1.3.x in tests on a Linux
> box! Incredimazing!
Nope... Not that much... If you consider that when you go non blocking, all
you have to do is parse the HTTP request, figure out where the file is, and
then tell the kernel to basically "copy" it over a socket (and call me back
when you're done), is not _that_ incredible...
It achieves performances really close to in-kernel HTTPD stacks, _very_
cool... Actually there's even a patch somewhere to allow Apache 1.3 to do
roughly the same thing with Solaris doors and stuff (it is somewhere split
between the Apache site and Sun's).
But _note_, there's one little caveat, it works AMAZINGLY fast, if you have
data in ram (and you can give it a pointer to it), or on disk. If you have
to dynamically generate requests, you won't be getting much better
performances out of it... Look at it as a parallel to the DMA as it is
implemented in hardware.
It works particularly well with a JVM because everything (threads included)
are virtualized, and in a hybrid situation, it would be amazing with the
Cocoon cache (using NIO, you can basically use the "old" 1 thread per
request when generating the cache, and then use the new "non-blocking" to
serve data OFF the cache).
(Ok, enough... I spent way too much time on high-performance network stacks
in the past 2 years! :-) I'm going _way_ offtopic!)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> ...there's too much confusion here, I can't get no relief.
>
> Besides quoting Bob Dylan, I'm *PISSED OFF* since I've spent the entire
> day trying to get Apache 2.0.x + Tomcat *.* working on Solaris and I
> decided to throw everything down the drain.
I feel your pain. That's why I use Caucho Resin instead... Although it
does have issues if you are dynamically generating graphics for the same
URI. It has an aggressive cache.
> I'll never use Tomcat again. Period. The phylosophy behind it (big
> servlet engine, light http stack on top) is plain wrong.
:)
The Haboob server built on SEDA has promise--although it is primarily a
research project. Imagine being able to gracefully handle 10,000
clients simultaneously with a proper scaling of performance--all in
Java. (it makes use of the NBIO library with JNI). It is no where
near Servlet compliant, but as a static HTML or simple CGI based server
that is impressive by any standard.
In fact this server outperformed Apache HTTPD 1.3.x in tests on a Linux
box! Incredimazing!
> Its connectors win the nobel price for cryptic configuration files and
> absent documentation (the first who says that cocoon docs sucks will
> have to figure out how to compile tomcat and connectors from source
> before being allowed to speak again)
>
> Moreover, there are *three* different tomcat implementations
> concurrently maintained.
>
> I'm sick of this.
>
> And I'm not alone.
No you aren't.
>
> Enough talking, expect action.
>
> Soon.
As we wait with baited breath...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Niclas Hedhman wrote:
<snip/>
>I wrote a simple HTTP server for Java 2 MicroEdition over the last weekend,
>with rudimentary Servlet-style support, not according to spec at all, just a
>simple Servlet interface with two methods.
>And even though I use a multithreaded approach, Threadpooling, RequestHandler
>pooling and support of SingleThreadModel interface (or multiple requests
>through the same initialized servlet concurrently), and even a miniature XML
>parser it is less than 100kB in size (a lot is debug messages, in total 239kB
>with the Ethernet driver and the J2ME CLDC class library).
>
>Next step is to squeeze XSL transformation in another 100k or so. Then tackle
>to get the rest of Cocoon inside, and then we have a Cocoon for PDAs. How
>about that? Hmmm.... Why? Because it can be done ;o)
>
Because it _is already_ done.
>Sylvain, I have decided to go my own way... Your quote on memory footprint was
>too much, only got 512kB for execution (Gates said I would never need more
>than 640kB, remember?)
>
The current footprint is without any optimisation of any kind and with
Saxon as the XSLT engine. Optimizing the bytecode and using XSLTC should
hopefully lead under the "Gates limit" !
But this is going off topic...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 03 February 2003 23:57, Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
> > I'll never use Tomcat again. Period. The phylosophy behind it (big
> > servlet engine, light http stack on top) is plain wrong.
> This made me remember those golden days when I was sticking to JServ
> and.refusing to switch to Tomcat unless being forced to... looks like I
> was forward looking then. :-/
Uhhh... Stop using JServ? Why? ;o) Still using it in my product. The switch to
Tomcat was not dirt-easy ( have a lot of WML generating servlets, and a
patched JServ to set content-type right... ), so why change something that
works.
> > Tomcat is getting bigger and slower every day and must do only one
> > stupid thing (connect a URI to a servlet, dah!) that we were able to do
> > in jserv with some 120Kb of java code. Talking about flexibility
> > syndrome. Hello? we already have a damn good web server!!! just because
> > you can't configure it doesn't mean you have to rewrite one from
> > scratch. get a life.
> Can't agree more. Even if when it comes to most sophisticate features
> (HTTP 1.1 as a first example) I understand that it's not that easy to
> implement a servlet engine in just a few lines of code.
I wrote a simple HTTP server for Java 2 MicroEdition over the last weekend,
with rudimentary Servlet-style support, not according to spec at all, just a
simple Servlet interface with two methods.
And even though I use a multithreaded approach, Threadpooling, RequestHandler
pooling and support of SingleThreadModel interface (or multiple requests
through the same initialized servlet concurrently), and even a miniature XML
parser it is less than 100kB in size (a lot is debug messages, in total 239kB
with the Ethernet driver and the J2ME CLDC class library).
Next step is to squeeze XSL transformation in another 100k or so. Then tackle
to get the rest of Cocoon inside, and then we have a Cocoon for PDAs. How
about that? Hmmm.... Why? Because it can be done ;o)
Sylvain, I have decided to go my own way... Your quote on memory footprint was
too much, only got 512kB for execution (Gates said I would never need more
than 640kB, remember?)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
> I'll never use Tomcat again. Period. The phylosophy behind it (big
> servlet engine, light http stack on top) is plain wrong.
>
> mod_jserv is not supported anymore. :(
>
> mod_jk is piece of [insert your favorite nasty word here] (who is the
> genious that invented the concept that the servlet engine should
> generate the configuration file for the web server module?).
>
> mod_jk2 is even worse (who invented its configuration format must think
> in sanscrit and never heard of virtual hosts).
>
> mod_webapp (which is the only *human* one) is dead.
This made me remember those golden days when I was sticking to JServ
and.refusing to switch to Tomcat unless being forced to... looks like I
was forward looking then. :-/
> Tomcat is getting bigger and slower every day and must do only one
> stupid thing (connect a URI to a servlet, dah!) that we were able to do
> in jserv with some 120Kb of java code. Talking about flexibility
> syndrome. Hello? we already have a damn good web server!!! just because
> you can't configure it doesn't mean you have to rewrite one from
> scratch. get a life.
Can't agree more. Even if when it comes to most sophisticate features
(HTTP 1.1 as a first example) I understand that it's not that easy to
implement a servlet engine in just a few lines of code.
> I'm sick of this.
So am I.
> And I'm not alone.
Definitely.
> Enough talking, expect action.
Expect cooperation here!
Ciao,
--
Gianugo Rabellino
CTO
Pro-netics s.r.l.
http://www.pro-netics.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> ...there's too much confusion here, I can't get no relief.
>
> Besides quoting Bob Dylan, I'm *PISSED OFF* since I've spent the entire
> day trying to get Apache 2.0.x + Tomcat *.* working on Solaris and I
> decided to throw everything down the drain.
I feel your pain. That's why I use Caucho Resin instead... Although it
does have issues if you are dynamically generating graphics for the same
URI. It has an aggressive cache.
> I'll never use Tomcat again. Period. The phylosophy behind it (big
> servlet engine, light http stack on top) is plain wrong.
:)
The Haboob server built on SEDA has promise--although it is primarily a
research project. Imagine being able to gracefully handle 10,000
clients simultaneously with a proper scaling of performance--all in
Java. (it makes use of the NBIO library with JNI). It is no where
near Servlet compliant, but as a static HTML or simple CGI based server
that is impressive by any standard.
In fact this server outperformed Apache HTTPD 1.3.x in tests on a Linux
box! Incredimazing!
> Its connectors win the nobel price for cryptic configuration files and
> absent documentation (the first who says that cocoon docs sucks will
> have to figure out how to compile tomcat and connectors from source
> before being allowed to speak again)
>
> Moreover, there are *three* different tomcat implementations
> concurrently maintained.
>
> I'm sick of this.
>
> And I'm not alone.
No you aren't.
>
> Enough talking, expect action.
>
> Soon.
As we wait with baited breath...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
>>
>>> Well, you know where my native code for the connector is :-) Right
>>> now, my
>>> suggestion is: use Jetty and proxy-pass HTTP requests through Apache
>>> :-) In
>>> the long-ish term, we'll see! :-) :-)
>> This is where I'm heading now, and this is where I want to work in the
>> future. I think that a major addition to cocoon scalability (agreed,
>> not for webapps) would be a complete proxy-friendly support, including
>> etags, 304 and proxy request headers (if-modified-since, if-none-match
>> and the like). As of now we have cloned only the mod_expires
>> functionality (which proved to be a major performance boost in some
>> cases), but there's a long way to go before reaching Nirvana of
>> proxy-friendliness.
>
>
> I think that a document (even rough) explaining what's left to be done
> would help a great deal.
>
It's in my plan, I'm taking some random notes. They are too random ATM
to be understood (even by me :-)) but expect an RT (and possibly a Wiki
page) soon. Real soon. :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Stefano Mazzocchi <st...@apache.org>.
Gianugo Rabellino wrote:
> Pier Fumagalli wrote:
>
>> Well, you know where my native code for the connector is :-) Right
>> now, my
>> suggestion is: use Jetty and proxy-pass HTTP requests through Apache
>> :-) In
>> the long-ish term, we'll see! :-) :-)
>
>
> This is where I'm heading now, and this is where I want to work in the
> future. I think that a major addition to cocoon scalability (agreed, not
> for webapps) would be a complete proxy-friendly support, including
> etags, 304 and proxy request headers (if-modified-since, if-none-match
> and the like). As of now we have cloned only the mod_expires
> functionality (which proved to be a major performance boost in some
> cases), but there's a long way to go before reaching Nirvana of
> proxy-friendliness.
I think that a document (even rough) explaining what's left to be done
would help a great deal.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine neccesitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Berin Loritsch <bl...@apache.org>.
Gianugo Rabellino wrote:
> Pier Fumagalli wrote:
>
>>
>> Well, remember that now in Apache 2.0 mod_proxy and mod_cache are
>> separated,
>> so, if you achieve proxy "full support" using HTTP, you'll be able to
>> simply
>> replace the HTTP proxying module with something (Better? Faster? Is it
>> really needed?), and keep all that caching magic working at the same
>> time...
>
>
> Yep. Apache mod_proxy (+ mod_cache) for the average, Squid for more
> advanced users and Akamai for the huge boxes. :-)
>
>>
>> The only case where I see something different from mod_proxy to be used
>> would be in the case when you really need a lot of thrughput, and so
>> you can
>> use things like shared memory and unix sockets/pipes between Apache and
>> Cocoon to basically avoid the re-parsing of the HTTP protocol and be as
>> close to the client as possible (a some sort of mod_cocoon)...
>>
>> But of course that approach would mean having the Java code to rely on
>> something native, with the rather-obvious problems of portability and
>> maintainance... Quite complicated indeed... It wouldn't be 100% pure java
>> anymore...
>
>
> Just out of curiosity, what do you think of a NIO based, pure java,
> lightweight HTTP server? I'm talking about projects like SEDA and
> derivatives (http://sourceforge.net/projects/seda).
Yep. Although I am officially part of that effort, I have not been able
to do anything with it yet...
My plans which seemed well received is to clean up the API and make
Sandstorm more friendly to components. I am sure they will be happy
for any help.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [OT rant] there must be some way out of here...
Posted by Marco Rolappe <m_...@web.de>.
sorry to disturb, just have a tiny question:
> -----Ursprungliche Nachricht-----
> Von: cocoon-dev-return-36189-m_rolappe=web.de@xml.apache.org
> [mailto:cocoon-dev-return-36189-m_rolappe=web.de@xml.apache.org]Im
> Auftrag von Dirk-Willem van Gulik
> Gesendet: Dienstag, 4. Februar 2003 12:26
> An: cocoon-dev@xml.apache.org
> Betreff: Re: [OT rant] there must be some way out of here...
>
> filter weird/malicous requests and not to mention the ability to quickly
> reroute to the right 'sorry - java is bust again' page.
how would I do that? I mean the redirection to a 'restarting servlet' like
page?
tnx in advance
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Mon, 3 Feb 2003, Gianugo Rabellino wrote:
> Pier Fumagalli wrote:
> >
> > Well, remember that now in Apache 2.0 mod_proxy and mod_cache are separated,
> > so, if you achieve proxy "full support" using HTTP, you'll be able to simply
> > replace the HTTP proxying module with something (Better? Faster? Is it
> > really needed?), and keep all that caching magic working at the same time...
>
> Yep. Apache mod_proxy (+ mod_cache) for the average, Squid for more
> advanced users and Akamai for the huge boxes. :-)
Squid, nor Akamai, gives you the operational flexibility of the apache
httpd web server; redirect requests, syphon of static files and mmap them,
filter weird/malicous requests and not to mention the ability to quickly
reroute to the right 'sorry - java is bust again' page.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Gianugo Rabellino" <gi...@apache.org> wrote:
> Pier Fumagalli wrote:
>
>> Hm... I don't like squid that much... It doesn't allow you to do a bunch of
>> nifty stuff that Apache lets you do... It is a little bit faster, but speed
>> comes at a great price:
>>
>> For example, you can't direct people to a holding page when the servlet
>> container is down, and this is something that I definitely need in my
>> production environment,
>
> Good point.
Plus another bunch of gizmos that you can throw into your httpd.conf, once
you know your way around it... But it's more a "guruism" around a particular
piece of software than real knowledge...
> But when you say:
>
>> plus as the Java Virtual Machine, "squid" is a
>> single-process server, if the one process crashes, you'll have to wait for a
>> restart and basically unable to serve requests.
>
> and:
>
>> Performance is good, but you always have to see what you're going to loose.
>> As I said earlier, the main disadvantage of non-native solutions (or Squid,
>> for that matters), means that you are going to have ONE only process
>> listening to your port 80... That is not good.
>>
>> At least, it doesn't work for me, where hardware is not an issue, but
>> resilience is: I can throw in another E4500 to spread the load if I have
>> performance problems, but I cannot loose a hit (connection refused is not
>> acceptable in my workplace - although it still happens).
>
> I have somehow to disagree. There are other ways to achieve resilience,
> via redundancy and balancing (Foundry and Radware have both great
> solutions for that), and in every case where resilience was that
> important in my projects, I always resorted to external hardware doing
> the job for me (and much better than me, for that matter). And if you
> can throw another 4500 you can throw a WSD or a Server Iron for sure. :-)
At that point, it's I believe "preference"... I personally don't like
layer-3 switches and "intelligent" routers, as it'll be a nightmare when you
want to configure them... But hey, I'm old and an HTTPD fanatic :-)
I started doing this kind of stuff when no hardware up front was available
to handle proper load balancing and resilience, I might have to go back and
look back again at some possible alternative solutions...
Sure is that if I have a one-single-machine, either I use some multi-process
thinghy, or... Every single case, its solution I believe... You used to work
for an ISP, so you know your stuff around routers and switches, I always
worked with Apache, so I know my way inside HTTPd... :-) :-) :-)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Gianugo Rabellino <gi...@apache.org>.
Pier Fumagalli wrote:
> Hm... I don't like squid that much... It doesn't allow you to do a bunch of
> nifty stuff that Apache lets you do... It is a little bit faster, but speed
> comes at a great price:
>
> For example, you can't direct people to a holding page when the servlet
> container is down, and this is something that I definitely need in my
> production environment,
Good point. But when you say:
> plus as the Java Virtual Machine, "squid" is a
> single-process server, if the one process crashes, you'll have to wait for a
> restart and basically unable to serve requests.
and:
> Performance is good, but you always have to see what you're going to loose.
> As I said earlier, the main disadvantage of non-native solutions (or Squid,
> for that matters), means that you are going to have ONE only process
> listening to your port 80... That is not good.
>
> At least, it doesn't work for me, where hardware is not an issue, but
> resilience is: I can throw in another E4500 to spread the load if I have
> performance problems, but I cannot loose a hit (connection refused is not
> acceptable in my workplace - although it still happens).
I have somehow to disagree. There are other ways to achieve resilience,
via redundancy and balancing (Foundry and Radware have both great
solutions for that), and in every case where resilience was that
important in my projects, I always resorted to external hardware doing
the job for me (and much better than me, for that matter). And if you
can throw another 4500 you can throw a WSD or a Server Iron for sure. :-)
> Jetty too has a NIO adapter (I know that it is completely different from
> what your mentioning, I know) Greg was talking about something similar, but
> he mentioned that if you wanted to use NIO you'd better move away from the
> servlet spec (and I agree wholeheartedly).
That is exactly what I'm afraid to discover. The bad news is that most
probably if you can't deal with NIO you can't deal with nbio, no matter
if native or built-in. Stuck? We'll see. :-)
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Gianugo Rabellino" <gi...@apache.org> wrote:
> Pier Fumagalli wrote:
>>
>> Well, remember that now in Apache 2.0 mod_proxy and mod_cache are separated,
>> so, if you achieve proxy "full support" using HTTP, you'll be able to simply
>> replace the HTTP proxying module with something (Better? Faster? Is it
>> really needed?), and keep all that caching magic working at the same time...
>
> Yep. Apache mod_proxy (+ mod_cache) for the average, Squid for more
> advanced users and Akamai for the huge boxes. :-)
Hm... I don't like squid that much... It doesn't allow you to do a bunch of
nifty stuff that Apache lets you do... It is a little bit faster, but speed
comes at a great price:
For example, you can't direct people to a holding page when the servlet
container is down, and this is something that I definitely need in my
production environment, plus as the Java Virtual Machine, "squid" is a
single-process server, if the one process crashes, you'll have to wait for a
restart and basically unable to serve requests.
Apache, instead, being multi-process in core, gives a lot more flexibility,
if one of your processes dies, well, you got another N processes (possibly
multithreaded) running smoothly, and something is _ever_ bound to port 80
ready to answer to HTTP requests! :-)
>> The only case where I see something different from mod_proxy to be used
>> would be in the case when you really need a lot of thrughput, and so you can
>> use things like shared memory and unix sockets/pipes between Apache and
>> Cocoon to basically avoid the re-parsing of the HTTP protocol and be as
>> close to the client as possible (a some sort of mod_cocoon)...
>>
>> But of course that approach would mean having the Java code to rely on
>> something native, with the rather-obvious problems of portability and
>> maintainance... Quite complicated indeed... It wouldn't be 100% pure java
>> anymore...
>
> Just out of curiosity, what do you think of a NIO based, pure java,
> lightweight HTTP server? I'm talking about projects like SEDA and
> derivatives (http://sourceforge.net/projects/seda).
Performance is good, but you always have to see what you're going to loose.
As I said earlier, the main disadvantage of non-native solutions (or Squid,
for that matters), means that you are going to have ONE only process
listening to your port 80... That is not good.
At least, it doesn't work for me, where hardware is not an issue, but
resilience is: I can throw in another E4500 to spread the load if I have
performance problems, but I cannot loose a hit (connection refused is not
acceptable in my workplace - although it still happens).
Jetty too has a NIO adapter (I know that it is completely different from
what your mentioning, I know) Greg was talking about something similar, but
he mentioned that if you wanted to use NIO you'd better move away from the
servlet spec (and I agree wholeheartedly).
Apache 2.1 or 2.2 should also feature non-blocking IO, and that would be
native, therefore _MUCH_ faster, but so far, as I'm "stuck" on MacOS/X for
all my development, I'm still kinda far from the non-blocking IO world...
The 1.4.1 JDK for Darwin should come out soon (the pre-release versions are
fairly good), we'll see when it's out final! :-)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Gianugo Rabellino <gi...@apache.org>.
Pier Fumagalli wrote:
>
> Well, remember that now in Apache 2.0 mod_proxy and mod_cache are separated,
> so, if you achieve proxy "full support" using HTTP, you'll be able to simply
> replace the HTTP proxying module with something (Better? Faster? Is it
> really needed?), and keep all that caching magic working at the same time...
Yep. Apache mod_proxy (+ mod_cache) for the average, Squid for more
advanced users and Akamai for the huge boxes. :-)
>
> The only case where I see something different from mod_proxy to be used
> would be in the case when you really need a lot of thrughput, and so you can
> use things like shared memory and unix sockets/pipes between Apache and
> Cocoon to basically avoid the re-parsing of the HTTP protocol and be as
> close to the client as possible (a some sort of mod_cocoon)...
>
> But of course that approach would mean having the Java code to rely on
> something native, with the rather-obvious problems of portability and
> maintainance... Quite complicated indeed... It wouldn't be 100% pure java
> anymore...
Just out of curiosity, what do you think of a NIO based, pure java,
lightweight HTTP server? I'm talking about projects like SEDA and
derivatives (http://sourceforge.net/projects/seda).
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Gianugo Rabellino" <gi...@apache.org> wrote:
> Pier Fumagalli wrote:
>
>> Well, you know where my native code for the connector is :-) Right now, my
>> suggestion is: use Jetty and proxy-pass HTTP requests through Apache :-) In
>> the long-ish term, we'll see! :-) :-)
>
> This is where I'm heading now, and this is where I want to work in the
> future. I think that a major addition to cocoon scalability (agreed, not
> for webapps) would be a complete proxy-friendly support, including
> etags, 304 and proxy request headers (if-modified-since, if-none-match
> and the like). As of now we have cloned only the mod_expires
> functionality (which proved to be a major performance boost in some
> cases), but there's a long way to go before reaching Nirvana of
> proxy-friendliness.
Well, remember that now in Apache 2.0 mod_proxy and mod_cache are separated,
so, if you achieve proxy "full support" using HTTP, you'll be able to simply
replace the HTTP proxying module with something (Better? Faster? Is it
really needed?), and keep all that caching magic working at the same time...
The only case where I see something different from mod_proxy to be used
would be in the case when you really need a lot of thrughput, and so you can
use things like shared memory and unix sockets/pipes between Apache and
Cocoon to basically avoid the re-parsing of the HTTP protocol and be as
close to the client as possible (a some sort of mod_cocoon)...
But of course that approach would mean having the Java code to rely on
something native, with the rather-obvious problems of portability and
maintainance... Quite complicated indeed... It wouldn't be 100% pure java
anymore...
That's why (alongside with time constraints) I'm hesitant...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Gianugo Rabellino <gi...@apache.org>.
Pier Fumagalli wrote:
> Well, you know where my native code for the connector is :-) Right now, my
> suggestion is: use Jetty and proxy-pass HTTP requests through Apache :-) In
> the long-ish term, we'll see! :-) :-)
This is where I'm heading now, and this is where I want to work in the
future. I think that a major addition to cocoon scalability (agreed, not
for webapps) would be a complete proxy-friendly support, including
etags, 304 and proxy request headers (if-modified-since, if-none-match
and the like). As of now we have cloned only the mod_expires
functionality (which proved to be a major performance boost in some
cases), but there's a long way to go before reaching Nirvana of
proxy-friendliness.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Stefano Mazzocchi" <st...@apache.org> wrote:
>
> ...there's too much confusion here, I can't get no relief.
>
> Besides quoting Bob Dylan, I'm *PISSED OFF* since I've spent the entire
> day trying to get Apache 2.0.x + Tomcat *.* working on Solaris and I
> decided to throw everything down the drain.
>
> I'll never use Tomcat again. Period. The phylosophy behind it (big
> servlet engine, light http stack on top) is plain wrong.
Well, why do you think I left that project??? :-)
> mod_jserv is not supported anymore. :(
Poor baby of mine! :-)
> mod_jk is piece of [insert your favorite nasty word here] (who is the
> genious that invented the concept that the servlet engine should
> generate the configuration file for the web server module?).
Do you want a name now? Nah, we don't want to start a flamewar (again).
> mod_jk2 is even worse (who invented its configuration format must think
> in sanscrit and never heard of virtual hosts).
Hahahahaha! :-) Old Egyptian is easier :-)
> mod_webapp (which is the only *human* one) is dead.
My baby part 2... I know, it was sad to "leave it behind", but consciously,
it couldn't have been integrated in the Tomcat stack anyway: I would have
had to rewrite major parts of the Tomcat internals to make it work
"properly"...
> Tomcat is getting bigger and slower every day and must do only one
> stupid thing (connect a URI to a servlet, dah!) that we were able to do
> in jserv with some 120Kb of java code. Talking about flexibility
> syndrome.
Well, Jetty does what Tomcat does in 1/2 a meg, it is faster, and yeah,
there are some bugs, but the people behind it are nice (well, you've met
Greg yourself, and he's a great guy).
Once we get some incompliancy issues sorted out. You have to admit that
Cocoon uses 101% of the servlet container, so stuff like deployment under
"/" (being the default servlet) is not something that everyone does.
Once we sort out all the issues, and have Jetty working for us, IMO, we're
going to have a very workable solution.
> Hello? we already have a damn good web server!!! just because
> you can't configure it doesn't mean you have to rewrite one from
> scratch. get a life.
Yes, indeed, Apache is _da_ webserver... I wouldn't run even my 2-hits/month
of my home page without it... It's just its design
(multi-process/multi-thread) which makes so much sense... You CAN'T crash
it.
On nagoya, to connect Tomcat and Apache I use mod_proxy which works just
_fine_, and really, you don't need much more unless you don't start having a
_shuvload_ of requests...
I see a connector != from mod_proxy only when you'll need to go down to
native to get performance out of it... But that's a choice you have to
carefully evaluate...
> Its connectors win the nobel price for cryptic configuration files and
> absent documentation (the first who says that cocoon docs sucks will
> have to figure out how to compile tomcat and connectors from source
> before being allowed to speak again)
:-)
> Moreover, there are *three* different tomcat implementations
> concurrently maintained.
Err... There are 4 implementations... 3.3, 4.0, 4.1 and 5.0 :-)
> I'm sick of this.
> And I'm not alone.
> Enough talking, expect action.
> Soon.
Well, you know where my native code for the connector is :-) Right now, my
suggestion is: use Jetty and proxy-pass HTTP requests through Apache :-) In
the long-ish term, we'll see! :-) :-)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT rant] there must be some way out of here...
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, Feb 3, 2003, at 15:57 Europe/London, Stefano Mazzocchi wrote:
> I'm sick of this.
>
> And I'm not alone.
>
> Enough talking, expect action.
>
Hear Hear!!!
You may remember me moaning about this the other day .... my heartfelt
commiserations!
Keep up the good work Pier! Stroll on Jetty! (or better!)
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org