Otherwise, I myself would tend towards a "push" model, since that's really more in line with how most web development is done. So, have the data collection servers push the records to the central server instead, whether queues are involved or not.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
phil campaigne wrote:
Frank W. Zammetti wrote:
Frank,
Dennis Payne wrote:
Frank,
I'm using threads and didn't know I was vulnerable.
I'm not sure "vulnerable" is really the right word, but I'll go with it :)
Here's how I've done it. I created a class that implements runnable and call its initialize method from a servlet init method at application startup. The initialize method creates a thread and sets a low priority for it.
Roughly what I do too, except that my class extends Thread and I kick it off from a Struts plug-in. Same effect though.
The run method sleeps the thread and wakes it every two minutes.
A processing class contains the methods that queries the database (postgres).
Same here. I think I wake my threads every minute though.
1. Is this what you call a daemon thread?
Nope. If you take a peak at the javadocs for the Thread class, you'll see a method setDaemon(boolean). This marks a thread as a daemon thread. The difference, if I remember correctly, is that the JVM won't shut down until all remaining threads are daemon threads. Threfore, if you spawn a "normal" thread, you can hold up the JVM from shutting down properly.
This is in fact the situation I had... My Tomcat instance could never be properly shut down because the threads I had spawned where not daemon threads. Marking them as such solved that problem.
To the best of my knowledge, being a daemon thread doesn't implicitly say anything about a threads priority. I think you could have a daemon thread set at high priority if you wanted. I suspect most daemon threads are bumped to a lower priority though, as I do.
2. Is this better done using cron? if so how do I ensure that it runs
with a lower priority than my application code? Phil
This is a matter of opinion, and there are some reasonable arguments for both points of view.
My personal opinion is that if you have some periodic process that is going to need portions of your system, whether it's resources available in the container or shared code, as you do, then a low-priority daemon thread spawned at application startup is a good approach, assuming you write it carefully and solidly.
For instance, in my case, my daemon threads do some record aging in the database, so to me it makes sense to share the same connection pool as the application itself. I also use a number of classes and functions that are part of the webapp itself, and I don't like the idea of duplicating the code for a cron job to use (sure, could just be a matter of setting up a classpath to those classes, but it's an extra dependency, and that doesn't thrill me).
But, if these tasks were volatile in any way, or they had to run independently of the app itself no matter what, the cron job approach would probably be preferable.
As for ensuring it runs at a lower priority than your application code, when running via cron, that's an answer I can't give you. I'm frankly a Unix newbie, more or less, so someone else out there would be better suited to answer that. I think you'd have to have it run at a lower priority than your app server, and I'm sure there's switches to set priority of jobs, but I don't know them.
I also am doing record aging. I want to move records older than two minutes to a centralized server for processing. Think of it as multiple data collection servers and a centralized data processing server. I'm thinking that the daemon to schedule queries against the data collection servers should execute on the centralized server. I'm wonder if this form of light weight replication is a good practice. Does anyone have some insite on this?
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
