JRuby & Eventmachine HTTP Server


#1

The eventmachine gem java version works fine, but is there a java
version of “eventmachine_httpserver” ?
The only version I can find is the C based one.

Thanks
Paul F.


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#2

Paul F. wrote:

The eventmachine gem java version works fine, but is there a java
version of “eventmachine_httpserver” ?
The only version I can find is the C based one.

Hmm, not that I know of. What does the additional C code do? HTTP
request parsing or something?

Anyone tried “evented mongrel” under JRuby + EM?

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#3

Charles Oliver N. wrote:

  • Charlie

HTTP request parsing is what I am after.
A parser exhibiting a simple api and called something like “HTTP
Parser” :slight_smile:
I may be wrong, but the java code I have checked out has the HTTP
parsing spread all over the place and hidden within (far from
descriptive) class names.

I am experimenting with the code covered in
http://www.igvita.com/2009/04/20/ruby-proxies-for-scale-and-monitoring/
A java verson of the “eventmachine_httpserver-0.1.1” gem would be very
handy in this proxy environment, but a simple java parser could also be
used.

Paul F.


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#4

I’ve been meaning to write some JRuby web servers using Mina and/or
Netty (async sockets, very event-driven and super fast) but I just
don’t have the free time for it. I think that would be a great option
for JRuby web apps.

On Wed, Apr 29, 2009 at 8:45 AM, Paul F. removed_email_address@domain.invalid
wrote:

I am experimenting with the code covered in

 http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#5

Kevin W. wrote:

I’ve been meaning to write some JRuby web servers using Mina and/or
Netty (async sockets, very event-driven and super fast) but I just
don’t have the free time for it. I think that would be a great option
for JRuby web apps.

On Wed, Apr 29, 2009 at 8:45 AM, Paul F. removed_email_address@domain.invalid wrote:

Hi Kevin,

Speaking from a NON Java background, I have found the Mina and Grizzly
HTTP stuff impossible to follow, it seems to be all over the place, and
the getters and setters are a pain in the **** when trying to follow the
code.
The eventmachine code and examples are elegent and easy to use, very
much in the Ruby mould.
Just a pity that the http stuff seems to be only in C.

Paul F.


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#6

Further research into this subject turned up “Http11Parser.java” found
in github/mongrel.
Mongrel java code seems very neat, readable and useful.

Paul F.


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#7

Yeah, it’s generated from Ragel, so it’s not even really
Mongrel-dependent and should be easy to repurpose. I’m actually a little
surprised the EM HTTP server didn’t just depend on Mongrel and reuse the
parser.

Paul F. wrote:

much in the Ruby mould.


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#8

I think a JRuby web server would simply expose Rack support and not
expose any Mina/Grizzly/Netty details to the JRuby user - basically
filling the C gap found in EM, Thin, Ebb, Mongrel, etc. I totally
agree it’s complex code, but it’s not impossible and it is wicked fast
and is pure Java. I’m not impressed by EventMachine much in general,
so I’m constantly looking for alternatives. I’ve started coding a
JRuby web server twice now and just can’t seem to find time to get
even close to finishing one.

You should be able to take the HTTP parser jar from mongrel-java and
invoke that in your EM handler code. That is similar to what I’m
trying to do in Thin, I just need to also replicate the Thin C code in
Java to make it all come together.

On Wed, Apr 29, 2009 at 7:26 PM, Paul F. removed_email_address@domain.invalid
wrote:

Hi Kevin,

To unsubscribe from this list, please visit:

 http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#9

It’s worth pointing out that this is largely what the GlassFish gem is
intended to do. There’s little more in the GF gem than Grizzly, some
classloading and configuration plumbing, and the JRuby integration bits
for Rails, Merb, and Rack. If it were possible to contribute to that
gem, it already has a great start.

Vivek or Jacob, maybe you can offer some tips on where to get started?

Kevin W. wrote:

invoke that in your EM handler code. That is similar to what I’m

On Wed, Apr 29, 2009 at 8:45 AM, Paul F. removed_email_address@domain.invalid wrote:
Paul F.
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#10

I’ve tried to get the internals of GF (and by extension the Gem) to be
as easily extendable as possible, though the Java side of things ends up
being a bit difficult to follow, so people wanting to write a web server
may be frustrated by some of the plumbing. We already expose Rack as
best we can, though, so I would think that an easy and Ruby-friendly way
to contribute there would be in writing additional framework
auto-loaders. We’ve already got Rails, Merb, and Sinatra (and the
Sinatra one apparently automagically works with Ramaze, too), but more
are always better. A framework auto-loader is just a bit of Ruby code
that will return an initialized app object, identical to what would be
passed in to mongrel etc. on startup. Something that a call to call(env)
will work on.

Architecture-wise, GF Gem is a bit odd, since it brings the server up
first and then starts the app, rather than the app starting the server
of its choice. That means that we need bits of gluecode for each
framework that we want to support, but it means that a) we can keep the
same core codebase in both Gem and server, b) Ruby programmers don’t
have to call in to Java to get the server started, and c) we can do all
kinds of fun things behind the scenes because we control the environment
that the apps are executing in. The runtime pool is probably the most
visible example of that kind of thing.

Charles Oliver N. wrote:

expose any Mina/Grizzly/Netty details to the JRuby user - basically
Java to make it all come together.

wrote:
the Ruby mould.

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email