Migration from Java?

[Tim Lavoie]

Hello all,

I've stumbled across Erlang fairly recently, and have started reading,
stepping through tutorials and so on. So far, so good! This has been
primarily for my own interest, so far, but I can see where it might
scratch an itch or two for my employer as well. It hasn't been
suggested yet, never mind approved, but I would like to explore the
ways in which Erlang might help, as well as any land mines to avoid.

Perhaps it would be helpful to describe the current scenario to some
degree, and where I see Erlang being helpful.

Our current environment is modular, running on a variety of hardware
and operating systems, with a web-based interface. A Java app server
runs the front part, perhaps with a separate web server out in front,
handling static content. The Java app is the main piece I'm involved
with, and it touches everything. XSL templates are used to generate
the pages dynamically, and a relational database is used fairly
extensively. Also, some operations involve passing beefy chunks of XML
to a separate number-crunching server, which can run for minutes on
end.

I'm not expecting to get anyone to make huge changes any time soon,
but would like to at demonstrate that there are alternatives to some
design choices which might be good to know about. If that helps
improve things down the road, I'm happy.

My main area of concern tends to be performance, so I have run
repeatedly into areas which could use help. 

First, XSL. I understand now why it was chosen, back in the mists of
time. I don't know that Erlang is able to help directly here, but it
does cause headaches. Even if things stay in Java, there is some hope
that this will go away. It's fine for morphing documents on occasion,
but brutal when generating many large, dynamic pages while someone is
waiting. Incidentally, my boss was the original architect, but took it
well when I ranted unwittingly about this particular ugliness in his
baby. I'm guessing there is hope for future change.  <grin>

Now, the main issue as I see it is that scalability is a problem. The
performance woes are less apparent when subjected to few users, and
the application server layer can be scaled with more hardware... given
sufficient will and resources.  Still, a few dozen users on this large
app, and the app server is suffering badly. 

One area I can see Erlang's approach helping is with asyncronous I/O,
combined with message passing. Right now, everything effectively
blocks sequentially. Page transitions mean that current state gets
written to the database, though most often this is "just in
case". Similarly, requests needing that back-end number cruncher
essentially tie up the user's browser until it comes back.

I can see the database writes being implemented as sending the message
to a process which handles the details, with the original web request
then continuing on its way without waiting. This isn't generally an
issue in my performance-test environment, but on client sites, with
different networking and servers, it creates delays. In the case where
the original process needs the result, it could ask for notification
back, and carry on from there.

The requests to the back-end server(s) are similar, and also block
until done. Some of these requests naturally take longer than others,
so I see Erlang as providing something of a more intelligent
queue. Now, all requests are spawned together, so they slow down if
there are more requests than processors. I'd like to see this as a
queue with a notification back, like the database. Also, since we know
what type of requests take much longer, Erlang's selective receive
mechanism is a natural for giving priority to those which should
return quickly.

Phew... Sorry, that was long-winded, and I still have questions.

 - Has anyone migrated a large project of this sort? How did it go? 

 - Is there some equivalent of Java's JDBC? Relational databases are
 pretty much a given, and persistent connection pools are pretty much
 required. I have seen mention of ODBC for Erlang; if this does the
 trick, particularly from Linux, that's a good start. Targets are the
 main RDBMS vendors, on several platforms.

 - Any other suggestions are naturally welcome.


   Thanks!
   Tim Lavoie