Threads and Load Balance

[Bob Rivers]

Hi,

We have a web application and due to the heavy traffic, my company
decided to put it under a load balance structure.

We are thinking about the usage of a "standard" load balance
structure:

Load Balancer
|
----------
| |
Server1 Server 2

I was doing some research, and I found some interesting solucions,
like the one described at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto.html.

But none of these solutions talk about threads. Into the jakarta
solution, they describe session replication. And what about threads?

My problem is that I have a thread that continuosly monitors a
database. If this monitor finds something (ie, the due date of an
order) it sends an email.

The problem is that this thread is (I think) attached to the web
server. If I have 2 (or more) servers, this thread will be started
twice, and someone will receive two emails....

So, how do I do threads under a load balance schema?

I am using simple servlets (with J2SE 1.3.1). The server that we are
using is tomcat 4.1.29.

TIA,

Bob

 

[Andy Fish]

obvious solutions would be:

(a) have the emailer thread run in a separate JRE not on the web server.

(b) use some kind of locking mechanism to ensure that only 1 web server is
trying to send emails e.g. have a table in the database which both servlets
will try to insert the same key value into. whoever succeeds gets the right
to send emails. The problem with this one is that you need to coordinate
startup/shutdown and possibly timeouts if one server crashes.

(c) have a status on the order table that says whether an email has been
sent. that way, whichever thread picks up the order first will send the
email. This is quite resilient but may mean extra work in your application.

 

[Hylander]

Hi,

We have a web application and due to the heavy traffic, my company
decided to put it under a load balance structure.

We are thinking about the usage of a "standard" load balance
structure:

Load Balancer
|
----------
| |
Server1 Server 2

I was doing some research, and I found some interesting solucions,
like the one described at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto.html.

But none of these solutions talk about threads. Into the jakarta
solution, they describe session replication. And what about threads?

My problem is that I have a thread that continuosly monitors a
database. If this monitor finds something (ie, the due date of an
order) it sends an email.

The problem is that this thread is (I think) attached to the web
server. If I have 2 (or more) servers, this thread will be started
twice, and someone will receive two emails....

So, how do I do threads under a load balance schema?

Probably programmatically use messages between servers to control
threads/start/check on threads. Perhaps designate one server as a
master in terms of thread control. You'll have a few cases to deal
with. ie: force one thread to take over if a failover situation
arises. Start up, (if one is down, what to do), if both are up, decide
which one starts and which one sleeps.

Messages of course can be done in a variety of ways....ie: plain
sockets, rmi, java's messaging APIs/message driven ejbs, etc etc. the
other post had some good ideas too. I'd try something simple and then
go from there. Anyone see anything wrong with this approach? (doing
your own threading is not kosher in EJBs btw but it doesn't mean you
can't hack it given you know your implementation and don't mind the
potential drawbacks...some might be serious enough to avoid such
things. you could try to do something more along the lines of a plain
message driven system. Your requirements might vary from what I'm
thinking too....some people want preemptive abilities/realtiming....in
which case, you might want to check if your OS supports it or has a
modified kernel available.)

 

[Jared Dykstra]

obvious solutions would be:

(a) have the emailer thread run in a separate JRE not on the web server.

(b) use some kind of locking mechanism to ensure that only 1 web server is
trying to send emails e.g. have a table in the database which both servlets
will try to insert the same key value into. whoever succeeds gets the right
to send emails. The problem with this one is that you need to coordinate
startup/shutdown and possibly timeouts if one server crashes.

(c) have a status on the order table that says whether an email has been
sent. that way, whichever thread picks up the order first will send the
email. This is quite resilient but may mean extra work in your application.

No matter what, you're going to have to separate this process from
your servlet. If you stop and think about it, it really doesn't make
sense for a servlet to be more concerned about changes to a database
than incoming web traffic.

Solutions (b) and (c) above will both sort-of work, except leave the
door wide open to a classic race condition. The simplest solution is
to simply go with (a) and write something else to handle
notifications.

I assume a servlet is responsible for changes to the database. If
certain page requests always preceed the database change you're
looking for, have the servlet check to see if an email is required as
the last thing. The request will only go to one server so you don't
have to worry about duplication in this case.

If you are using a database that supports triggers, then use them.
Rather than poll your database server continuiously, let it notify you
when something important happens.

 

[Roedy Green]

Jared Dykstra

By any chance are you related to THE Edsger Dykstra?

 

[Jared Dykstra]

By any chance are you related to THE Edsger Dykstra?

LOL, I didn't know my message was *that* profound ;-)