struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Reumann <>
Subject Re: Interesting problem...
Date Fri, 18 Mar 2005 19:20:14 GMT
I posed your question to a colleague of mine, because this problem is 
way beyond my puny knowledge. Anyway, his response, for what it's worth:

My first instinct is to call this a Supremely Bad Idea.  There WILL be
conflicts.  You can bet on it.  Best to have a single "maintenance"
process on a single host that fails over as needed.  Alternatively, rely
on shared/exclusive table-level locking which is extremely efficient,
widely supported, and does not suffer from the issues that row-level
locking is famous for.

If the random number generator is still insisted upon, there are
standard solutions for seeding it.  The class
uses host and network performance and latency metrics to seed itself.
While that might not be quite as well-seeded as a "pot of boiling
water", it's pretty darn close.

If that's not sufficient and you're running on a UNIX-style system
(Linux, BSD, Solaris, etc), you can read a block from /dev/random and
seed your generator with that.  It's a system-level random state that
survives reboot.

Finally, you can seed it with a UUID.  Most containers these days
provide some sort of UUID service, and if not then there are example
UUID generators all over the net.

<original uncommented post left below for reference:>

Frank W. Zammetti wrote the following on 3/18/2005 10:35 AM:
> Oh boy, I got a good one!  It's only related to Struts in that the
> application in question is Struts-based, so I hope no one minds a semi-OT
> question...
> Here's the situation... An app I wrote has a daemon thread that is spawned
> at startup (from a Struts plugin) that does periodic background processing
> tasks.  This works great, never had a bit of trouble.
> Now though, the app is moving from a single server to a clusted environment.
> So, what's going to happen is that each server in the cluster will have
> its own instance of the thread running on it.  Not a huge problem except
> that I have to be sure only one instance of the thread (i.e., one server
> in the cluster) is executing concurrently.
> The easy solution is just a database table that is checked when the thread
> wakes up.  If there is no entry in it, then there is no other instance
> running, so it can write an entry to the table and go off and do its
> thing.
> I want to be extremely certain that no issues arise in terms of one
> instance of the thread reading from the database while another instance is
> writing, etc.  So, aside from transactional database calls and row-level
> locking, I want to do one more thing: I want the thread to sleep a random
> number of seconds (1-300) at startup.  This will ensure that, all the
> database locking and such aside, the threads should all be offset from one
> another in terms of when they run.
> So, I need a random number generated when the thread starts up.  As we all
> know though, random number generation on most computers that don't have
> something like a Brownian motion sensor attached stuck in a cup of boiling
> coffee can't generate truly random numbers.  So, in theory, what could
> happen is that if all the servers in the cluster come up at the same time,
> the threads could wind up running at the same time regardless of the
> random sleep at the start!  It might never happen in reality, small
> fluctuations would probably offset them anyway, but I want to be more
> certain than that.
> So now we're at the crux of the problem...
> I can't just seed the random number generator with the current time
> because it concievably might not be random enough.  So, I thought I could
> just tally up the octets of the server's IP address and add that to the
> current time.  Then the seed on each server should be different enough.
> But, there doesn't appear to be any way to get the server IP address
> independant of a request, so I can't get at it in my plugin.  Anyone know
> differently?
> Assuming that is the case, can anyone think of any other way to seed the
> generator that would ensure a different value on different machines in the
> cluster?  There are some options like encoding the individual server names
> in my app's config file with a different seed value for each, but that
> makes maintenance a pain if a new server is added or one removed or
> addresses simply changed.
> Any ideas?  Thanks!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message