Server Programming

[Andy Stone]

Hello all,

The company I work for currently utilizes JAVA/JSP, ORACLE 9i,
Apache,Tomcat setup running on Solaris. We have plans to migrate to
PostgreSQL and Linux. Currently I have an issue with a server written
in JAVA that hangs about once a week (don't know exactly why yet -
hence the vague term) and we recently had it create a defunct port
while trying to shut down. I did not write this server, but am the
only one left to maintain this code.

Now you know why I am here. I am looking into Ruby as an alternative
to this JAVA Server. The core functionality needed would be processing
zip files, parsing text/binary files and executing sql statements.

At this stage, how does Ruby compare to Java in terms of server
programming? I have liked everything I've read about Ruby to date,
but have seen very little in reference to server programming, but then
again, I'm just beginning.

Please excuse the vagueness, I'm very undecided what to do right now,
rewrite the JAVA Server in another language or rewrite it with JAVA,
but correctly. The main reason for the other language consideration
is the text and binary file processing. I'm was thinking Ruby might
handle this aspect better than JAVA.

thanks,
andy

 

[Francis Hwang]

Hi Andy,

What's the server part of this? I understand processing zip files,
parsing text/binary, executing SQL, all of that, but I think you've
been a little vague as to how all these actions fit into the overall
function of the server in your company. Is this a web server, then I
take it? Or some other sort of server?

At any rate, everything you've said so far can be handled fine in Ruby,
and you'll probably find it a lot more fun to write than in Java. If
you have other specific concerns you should just bring them up and we
can address them.

Francis

 

[Dido Sevilla]

Now you know why I am here. I am looking into Ruby as an alternative
to this JAVA Server. The core functionality needed would be processing
zip files, parsing text/binary files and executing sql statements.

This is all par for the course. Ruby is very much capable of all these
things, but there are certain DBD's that aren't as well maintained as
others, so knowing what your database backend is would be useful
(specifically it would appear that the Sybase driver is woefully out
of date).

Ruby is in my opinion a much, much more elegantly pleasant language to
work with than Java will ever be.

At this stage, how does Ruby compare to Java in terms of server
programming?

I assume you mean web server programming. More generic application
server programming is also doable and most of the common protocols
already have direct support by the Ruby core (e.g. http, smtp,
pop/imap, and so forth).

I have liked everything I've read about Ruby to date,
but have seen very little in reference to server programming, but then
again, I'm just beginning.

Try going to http://www.rubyonrails.org/

It's an MVC framework like the Apache Project's Jakarta Struts, but it
is in my experience a lot simpler and easier to program in. As they
put it, you'll be able to build a full-featured web application using
less lines of code than many other frameworks use for their XML
configuration files...

 

[Andy Stone]

Hello Francis,

Thanks for the reply.

This isn't a web server, just a JAVA client/server application that
starts a few threads that have their own individual responsibilities.
The server app is merely a container for these threads to allow the
basic functions like startup,shutdown,and status to be handled
cleanly.

Being that I don't have any specific questions, I'll just start
writing a version in Ruby and will post questions (as they arise) to
answers I can't find elsewhere.


Thanks again,
andy

 

[David Ross]

My project usage with Ruby comes pretty close to what you are using it
for with your project.

Recently I created a SOAP client/server which were seperate handling
frontend and backend for customers to access company information. The
program handled authentication, database access, and scripts that ran
every night updating any information changed from external data formats.
Ruby runs fine for server/client applications. I hgive it a big A+. I've
had a few problems sure, but the Japanese Ruby community are really
nice. There are some nice non-ignorant people out there as well, usually
you can find them on IRC(note: there are still ignorant ones out there).
Thanks to NaHi I was able to complete my applications. Ruby is very good
for what ou have in mind.

If you need help, drop by on
irc://irc.efnet.net/ruby-lang
or
irc://irc.freenode.net/rubymine

I would be glad to answer any questions you have.


David Ross

 

[Andy Stone]

Thanks for the reply Dido,

My hope is that Ruby is not only a a more elegant and easier language
to use, but will also handle this task more efficiently with fewer
issues than I currently have. Of course that is very touch metric
because the problems with the current Java implementation could have
nothing to do with Java, just bad code.

As I just replied to Francis, I will just jump into this and see what happens.

I guess I'm just bored with Java, have an issue that needs fixing and
am looking for a change.

thanks again,
andy

 

[Joel VanderWerf]

Hello Francis,

Thanks for the reply.

This isn't a web server, just a JAVA client/server application that
starts a few threads that have their own individual responsibilities.
The server app is merely a container for these threads to allow the
basic functions like startup,shutdown,and status to be handled
cleanly.

Note that ruby threads are in-process threads, so if you're using
threads to take advantage of multiple cpus, you may want to have several
ruby processes on the server side, and distribute tasks among them.

Also, take a loook at DRb--distributed ruby. It's a remote method call
protocol for ruby objects and a very elegant way of developing servers,
though it doesn't come without some performance costs. A good starting
place is the pickaxe book (get it online at
http://www.rubycentral.com/book/index.html or buy the new edition).

DRb even has a Linda/tuplespace implementation, called Rinda. All
included with ruby in the standard lib.

 

[Andy Stone]

David,

Thanks for your reply. It's very good to hear that!

I'll only bug you guys if I've exhausted everything else.

thanks again! It's real nice to see this kind of response.

-andy

 

[Andy Stone]

Joel,

Thanks for the thread and DRb info. Performance is a main concern
with this application, so it doesn't sound like the right course for
me to take, but I will look into it before ruling it out.

-andy

 

[James Edward Gray II]

Joel,

Thanks for the thread and DRb info. Performance is a main concern
with this application, so it doesn't sound like the right course for
me to take, but I will look into it before ruling it out.

Ugh. I hate to throw a bad light on Ruby, but it's probably true that
Ruby is generally a little slower than Java in most things. Just want
you to be aware of that going into this.

James Edward Gray II

 

[Andy Stone]

Would you say it's slower in processing text files? A single file can
run a few megabytes. That's where I was hoping to gain some speed from
Ruby. I was thinking that Ruby would be a little slower in other
aspects, but thought that I would make up considerable ground with the
parsing process.

 

[James Edward Gray II]

Would you say it's slower in processing text files? A single file can
run a few megabytes. That's where I was hoping to gain some speed from
Ruby. I was thinking that Ruby would be a little slower in other
aspects, but thought that I would make up considerable ground with the
parsing process.

Speed is a dangerous question always. I'm a skilled Java programmer
(day job) and I have to tell you true, I BELIEVE I can write faster
Java code. Of course, I can write slower too and I certainly write
code faster in Ruby (and have more fun doing it). It's a complex
question you ask. Benchmark for sure.

James Edward Gray II

 

[Andy Stone]

I agree. In relation to a process, the overall speed can be affected
by many factors including code design, database design and... I could
go on, but I'm sure you already know all of this.

If there was a choice, I would trade some speed for reliability any
day. What good is a super fast process if it crashes from time to
time?

I heard that comment a lot about writing code faster with Ruby. Which
is one of the main reasons I am evaluating Ruby. As the sole
developer at the day job, maintaining two entirely different and in
some areas, complex web sites along with the intranet, this aspect of
Ruby could help me out tremendously.

I know there's no "holy grail" for computer languages, but I'm always
looking.

 

[James Edward Gray II]

I know there's no "holy grail" for computer languages, but I'm always
looking.

Then my suggestion is to play with Ruby a bit, if you can afford the
time. I program in Java because I have to, and Ruby because I love to.
Hopefully you'll feel the same.

Good luck with your project.

James Edward Gray II

 

[Brian Candler]

Also, take a loook at DRb--distributed ruby. It's a remote method call

protocol for ruby objects and a very elegant way of developing servers,
though it doesn't come without some performance costs. A good starting
place is the pickaxe book (get it online at
http://www.rubycentral.com/book/index.html or buy the new edition).

Also, there's now a page on the wiki at
http://www.rubygarden.org/ruby?DrbTutorial

 

[Robert Klemme]

I agree. In relation to a process, the overall speed can be affected
by many factors including code design, database design and... I could
go on, but I'm sure you already know all of this.

If there was a choice, I would trade some speed for reliability any
day. What good is a super fast process if it crashes from time to
time?

I heard that comment a lot about writing code faster with Ruby. Which
is one of the main reasons I am evaluating Ruby. As the sole
developer at the day job, maintaining two entirely different and in
some areas, complex web sites along with the intranet, this aspect of
Ruby could help me out tremendously.

OTOH you have to write the code from scratch, i.e. you have increased
effort upfront. That may or may not be acceptable in your case. From
what I've read in this thread I'd have a slight tendency to stick with the
Java version, get me a copy of Eclipse (if you don't have it already) and
start a refactoring frenzy to get the code into better shape. It might
well be that the occasional hang is due to some threading problem which
came into existence through improper use of synchronization. *If* you go
down that road "Concurrent Programming in Java" (Doug Lea) is an excellent
reference. (It's also good as a general introduction of MT issues
though.)

Kind regards

robert

 

[David G. Andersen]

Would you say it's slower in processing text files? A single file can
run a few megabytes. That's where I was hoping to gain some speed from
Ruby. I was thinking that Ruby would be a little slower in other
aspects, but thought that I would make up considerable ground with the
parsing process.

Another view on this:

I just rewrote a lot of data processing scripts in Ruby. The
prior version was a mix of perl with a few speed-critical
functions implemented as standalone C programs. I _do_
care about speed with these -- a full analysis run on the
data we've got right now takes about a day and a half -- but
I also cared a lot about getting the programs done in time
for a conference deadline. The data is about 32 gigs gzipped.

The new version is about the same speed as the prior version, or
just a bit slower, because it's done right, and it was easier to
do right -- but doing line processing with Ruby 1.8 (which doesn't
have the new oniguruma regexp library) is noticably slower than
doing the same thing in perl if you're doing a lot of

if (l =~ /pattern/) ...

Doing it right resulted in the memory footprint dropping from
about 500MB to 7MB, which was pleasant, and avoiding some
stupidity in the perl code (which was pretty entrenched)
sped things up enough to compensate for the slowdowns.
I'm _very_ glad I took the time to rewrite it. I had to
do a few workarounds to avoid particular slowdowns in
Ruby (see my earlier thread about zlib slowness, in particular),
but it wasn't onerous.

But if you ignore programmer effort and the possibility
of better program structure, comparing the raw speed of
a JITted Java to Ruby is probably going to come down on the
side of Java. Of course, if you can easily implement your
"inner loop" functionality in C, you could always quickly
swig it and 'require' it from within ruby.

Interested to hear what you think after the project.

-Dave

 

[David Ross]

Another view on this:

I just rewrote a lot of data processing scripts in Ruby. The
prior version was a mix of perl with a few speed-critical
functions implemented as standalone C programs. I _do_
care about speed with these -- a full analysis run on the
data we've got right now takes about a day and a half -- but
I also cared a lot about getting the programs done in time
for a conference deadline. The data is about 32 gigs gzipped.

The new version is about the same speed as the prior version, or
just a bit slower, because it's done right, and it was easier to
do right -- but doing line processing with Ruby 1.8 (which doesn't
have the new oniguruma regexp library) is noticably slower than
doing the same thing in perl if you're doing a lot of

if (l =~ /pattern/) ...

Doing it right resulted in the memory footprint dropping from
about 500MB to 7MB, which was pleasant, and avoiding some
stupidity in the perl code (which was pretty entrenched)
sped things up enough to compensate for the slowdowns.
I'm _very_ glad I took the time to rewrite it. I had to
do a few workarounds to avoid particular slowdowns in
Ruby (see my earlier thread about zlib slowness, in particular),
but it wasn't onerous.

But if you ignore programmer effort and the possibility
of better program structure, comparing the raw speed of
a JITted Java to Ruby is probably going to come down on the
side of Java. Of course, if you can easily implement your
"inner loop" functionality in C, you could always quickly
swig it and 'require' it from within ruby.

Interested to hear what you think after the project.

-Dave

War stories. I wonder if theres already a page for it on RubyGarden, if
not it should be created. I'd love to hear about people who converted
program(s) from <that language> to Ruby. It would be interesting and
benificial to the community. Also it would encourage more to convert as
well.

David Ross

 

[Bill Guindon]

War stories. I wonder if theres already a page for it on RubyGarden, if
not it should be created. I'd love to hear about people who converted
program(s) from <that language> to Ruby. It would be interesting and
benificial to the community. Also it would encourage more to convert as
well.

Good idea, and it works the other way around also. atm, I'm taking
what I've learned from Ruby and bringing some of it to the world of
Miva. I've played with this idea for a couple of years, and it's
finally live, thanks to Ruby.

The months that I spent learning Ruby are paying off in ways I never
would have imagined, and without a doubt, it was well worth the time.
Ruby gave me a new perspective on some old code, and it gave me some
new tools to generate code for the truly tedious parts of what I'm
doing.

In a nutshell, learning Ruby has put the "possible" in "impossible" (a
reverse of the old joke "they put the "fun" in "dysfunctional").

 

[Andy Stone]

It's good to hear the war stories. It seems I have a good one brewing.

My task is complicated by the fact that there is a good amount of
shared code between this client/server app and the web application
itself. This code is in the form of data objects responsible for
reading/writing to the database as well as representing the entities
of the project.

What I have found interesting about this whole process was stepping
back and reviewing the code architecture after a year of requirement
changes. Even though great consideration was taken in object design
it appears that the greatest flaw was in packaging. Don't get me
wrong, the client/server app definitely needs work (hence the reason
this started), but the project as a whole should have been taken into
account when the system was being designed. It seemed that the focus
was always so granular the big picture was never brought into view.
Of course, this has been an ugly, ugly (and one more time for
emphasis), ugly project from the beginning. I'm actually quite amazed
it's been working for so long.

So, now I have a system that requires this repackaging regardless of
going with Ruby or not. Over the next couple of days I will be doing
just that. Once I have tested the repackaging, I can then resume the
issue of what to do with this client/server app.

Any recommendations on a JAVA/Ruby interface? Is that a viable
option? There are other ways I can handle what I need to maintain
between the java web app and a ruby client/server app, I was just
curious if someone has come up with a real slick solution.

-andy