jcrontab works ok, it is modeled after the unix crontab entries.
Best bet is to try it and see if it meets ones needs :)
Anton Tagunov wrote:
So, what John is speaking about - spending
less effort on thread coding and using an
existing solution (native Unix crontab)
may also be pushing you to
You can create threads all day in tomcat, but here are the importnatn things
to consider:
- WHY! Are threads really the correct solution?
- If you create threads - what are their scope? Daemon, non-daemon?
- If you create non-daemon threads - be prepared for the consequences such as
the JVM not
Well, that was part of my question if I
cannot/don't implement daemon threads to do e.g.
automatic daily tasks, what else? E.g, at the end of
the day send an e-mail to a (real life) manager with a
summary of the day's transactions something like
that.
Does Tomcat provide some sort of
Hello Riaan, you might want to check out jcrontab.
http://jcrontab.sourceforge.net
Riaan Oberholzer wrote:
Well, that was part of my question if I
cannot/don't implement daemon threads to do e.g.
automatic daily tasks, what else? E.g, at the end of
the day send an e-mail to a (real life)
This looks promising, but what do they do differently
than just starting a deamon thread and doing some
background work?
Why bother with this if you can start your own custom
thread, or do they do something else?
--- Kwok Peng Tuck [EMAIL PROTECTED] wrote:
Hello Riaan, you might want to check
Tomcat doesn't provide this but other simple solutions exist such as exposing
a URL and using cron + wget. (Some may also say kludge too)
As for aggregating statistics - I would recommend using a log file to record
the essential measurements then running your stats program on the logs. This
... nice suggestion, but I am delivering an
application as a .war file to a 3rd party and they
just want the .war (+ context.xml) with everything in
it hence, no other applications checking the logs
or database. All functionality must come from the .war
running in Tomcat. It is very important:
cron = scheduler
wget = command line HTTP/HTTPS client
The requirement for delivering everything in a WAR file is all nice and
dandy, but if you think about it, the requirement automatically breaks
the other requirement: scheduling.
If you cannot have a log file, and you cannot access a
Perhaps I should give a better explanation of how the
application works:
I deliver a .war file. I do have access to an
underlying database. The scheduled tasks perform more
on a is time reached than has time elapsed
principle... eg, it triggers when is it past
midnight? instead of has 24 hours
Nobody, from what I can tell, is saying can't. You did ask, though.
If you're willing to be diligent about coding your threads, go for it.
I think the point of previous posts was that in many cases, there is no
need for such a thing as your asking. There are always exceptions to
the rule,
You're right, no-one said I can't. :) I was hoping
someone who has actually used it could give some
feedback about it.
The (obvious) reason why the scheduled task also
cannot be active if the web-app is not active, is that
the scheduled task requires users to use web-app. Eg,
Friday at 15:00 you
Howdy,
I cannot see why creating a daemon thread cannot cater
for this. You just start the thread in the init method
of the InitServlet (or any servlet you create with
start-when-app-starts).
I'm actually a fan of the background daemon-thread approach, and think
the user-threading limitations
Yep, thanks... I've heard from other sources as well
that the ServletContextListener approach is better.
It gives me some comfort knowing other people find the
approach safe and without too many pitfalls. :)
--- Shapira, Yoav [EMAIL PROTECTED] wrote:
Howdy,
I cannot see why creating a
From: Tim Funk funkman () joedog ! org
Subject: Re: [Q] Is it safe to create threads in Tomcat web-apps?
You can create threads all day in tomcat, but here are the importnatn things
to consider:
- WHY! Are threads really the correct solution?
- And last but not least: WHY! Are threads
I am in total agreement and I have used user created threads on my site. I
view user created threads as a dangerous and usually un-needed thing.
Dangerous because of the side effects that aren't accounted for by more
junior programmers such as concurrency, shutting down the JVM (or lack of
I hate to speak for someone else, but I believe that Tim may have been
referring to the tendency of some people to use threads without
understanding their limitations. (I've seen attempts to massively
thread CPU-bound applications on single CPU machines.)
Threads are not magic that can be spread
16 matches
Mail list logo