|
Replies:
9
-
Last Post:
Jul 17, 2008 1:03 AM
by: remisb
|
|
|
|
|
|
|
Running Java Applications as a back-end batch processes
Posted:
Jul 10, 2008 3:15 PM
|
|
|
Hi Everyone,
I am new to Java and Glassfish world. I was wondering if I could run multiple java applications, run them as daemon applications as soon as GlassFish is started. I am from Microsoft world and trying to run back-end processes similar to Microsoft Services. I want to be able to monitor the applications, start them and stop them. My applications should wake up every 30 min and communication with Telecommunication switches, MySQL and MSSQL. I have seen Lifecycle Modules in GlassFish. Can I use them. Please advice.
Can I use EJB 3.0 Timer Services??
Thanks,
Amir
Message was edited by: e3amir
|
|
|
|
|
|
|
Re: Running Java Applications as a back-end batch processes
Posted:
Jul 10, 2008 8:51 PM
in response to: e3amir
|
|
|
you could use Timer-services to do this; the start/stop can be done "out of the box" with the Glassfish app-server console.
This is not saying it's the best or only way to do what you want to do; there'd need to be a lot more information to answer the "what's best?" question, but you could certainly do that.
|
|
|
|
|
|
|
|
|
Re: Running Java Applications as a back-end batch processes
Posted:
Jul 10, 2008 8:57 PM
in response to: e3amir
|
|
|
You can run glassfish as a daemon, like a mysql server on windows machines. Logout from the graphical console and let the service running in background.
You can administer it by running a browser at admin port (4848) remotely and do all the management tasks.
For the timer tasks, I recommend to use ejb timer bean. The lifecycle is an api to applications have access to glassfish lifecycle, but it doesn't look what you want.
Claudio Miranda
|
|
|
|
|
|
|
|
|
Re: Running Java Applications as a back-end batch processes
Posted:
Jul 13, 2008 4:28 AM
in response to: claudio
|
|
|
Be careful with this solution. It's not as easy as is said. I had a lot of problems with it. If you are going to do batch processing with EJB timers, you have to be very careful. EJB timer allows you to call EJB stateless and statefull session beans and they does not allow you to access files. Most of the time patch processing is dealing with files.
Another issue, if you are going to move big amounts of data between files or different databases you will have long transaction. All data in that transaction will be collected in memory and released only after completion. You have to know amount of data and how much memory will be consumed during this process.
After I had developed solution, I looked into Spring batch http://static.springframework.org/spring-batch/ which can be better solution.
Development of batch processing tasks on glassfish was problematic and I got a lot of headache and sleepless nights, but at the end it works very well and I'm happy how stable and reliable it's.
Regards
Remis B
|
|
|
|
|
|
|
|
|
Re: Running Java Applications as a back-end batch processes
Posted:
Jul 15, 2008 8:12 PM
in response to: remisb
|
|
|
Thanks for your comment and warning. I will look into it.
|
|
|
|
|
|
|
|
|
Re: Running Java Applications as a back-end batch processes
Posted:
Jul 16, 2008 10:28 AM
in response to: remisb
|
|
|
> Be careful with this solution. It's not as easy as is
> said. I had a lot of problems with it. If you are
> going to do batch processing with EJB timers, you
> have to be very careful. EJB timer allows you to call
> EJB stateless and statefull session beans and they
> does not allow you to access files. Most of the time
> patch processing is dealing with files.
I call shenanigans.
Yes, the JEE spec considers file access by an EJB to be "unsupported" in terms of the spec. However, I don't know of a single container that actually enforces this restriction. The motivation behind it is that EJB is a distributed component framework, and in that light the intent is that EJBs can be deployed "anywhere", particularly in a clustered environment. In these cases, relying on the filesystem means you're relying on a "resource" that is not managed by the container. If it's not managed by the container, it's not "portable". If you want to be pure to spec, write a JCA resource to represent your file system.
But the reality is simply that most developers can actually work around the details of "knowing" where a component is deployed (perhaps it's not a clustered system, perhaps it's a configuration variable specifying a correct location, perhaps it's a network filesystem mapped to the path on every node).
Bottom line, files work fine in EJB. It's just not, per spec, "portable".
> Another issue, if you are going to move big amounts
> of data between files or different databases you will
> have long transaction. All data in that transaction
> will be collected in memory and released only after
> completion. You have to know amount of data and how
> much memory will be consumed during this process.
More shenanigans. Regarding databases specifically, I don't know of a single modern database who has transactions that are memory bound. Typical databases will have transactions log bound, assuming fixed log sizes configured for the database. There's no reason for a database to hold pending transactions in memory. It's insane, it has to write the data anyway.
Should you be concerned how much memory your processes take? Of course, but the database won't be your smoking gun and neither will the EJB transaction subsystem. It doesn't "remember" anything either.
Most problems with long running transactions in EJB systems revolve around network connection timeouts from clients. EJB Timers don't suffer that problem since they're local to the container (unless they themselves are network clients, for example calling a long running remote EJB session bean).
> Development of batch processing tasks on glassfish
> was problematic and I got a lot of headache and
> sleepless nights, but at the end it works very well
> and I'm happy how stable and reliable it's.
I'm glad he's happy with his Spring solution, but I'm very interested in more specifics about what his issues were.
|
|
|
|
|
|
|
|
|
Re: Running Java Applications as a back-end batch processes
Posted:
Jul 17, 2008 1:03 AM
in response to: whartung
|
|
|
> > Be careful with this solution. It's not as easy as
> is
> > said. I had a lot of problems with it. If you are
> > going to do batch processing with EJB timers, you
> > have to be very careful. EJB timer allows you to
> call
> > EJB stateless and statefull session beans and they
> > does not allow you to access files. Most of the
> time
> > patch processing is dealing with files.
>
> I call shenanigans.
>
> Yes, the JEE spec considers file access by an EJB to
> be "unsupported" in terms of the spec. However, I
> don't know of a single container that actually
> enforces this restriction. The motivation behind it
> is that EJB is a distributed component framework, and
> in that light the intent is that EJBs can be deployed
> "anywhere", particularly in a clustered environment.
> In these cases, relying on the filesystem means
> you're relying on a "resource" that is not managed by
> the container. If it's not managed by the container,
> it's not "portable". If you want to be pure to spec,
> write a JCA resource to represent your file system.
>
> But the reality is simply that most developers can
> actually work around the details of "knowing" where a
> component is deployed (perhaps it's not a clustered
> system, perhaps it's a configuration variable
> specifying a correct location, perhaps it's a network
> filesystem mapped to the path on every node).
>
> Bottom line, files work fine in EJB. It's just not,
> per spec, "portable".
>
Thanks, you said exactly what I meant. The reason I said that and stand firm on my words, that person before going to do something have to know all issues what he will face.
I don't understand this kind of attitude, this is like having suggestion from enemy. Go to that direction, if you will face any problem then, fuck off, you haven't asked about that, and if you will have to use JCA or anything else just to get access to files that's fine this is a life.
This attitude is very destructive, person can receives following experience:
1. that suggestions from forum can be very bad and it's better not to trust them.
2. Glassfish and Java EE is a devil's tools. It's better not to touch them at all, because you never know what next problem will come.
3. people what suggesting solutions care less about the person's problem, they more concerned about technology, not about me.
> > Another issue, if you are going to move big
> amounts
> > of data between files or different databases you
> will
> > have long transaction. All data in that
> transaction
> > will be collected in memory and released only
> after
> > completion. You have to know amount of data and
> how
> > much memory will be consumed during this process.
>
> More shenanigans. Regarding databases specifically, I
> don't know of a single modern database who has
> transactions that are memory bound. Typical databases
> will have transactions log bound, assuming fixed log
> sizes configured for the database. There's no reason
> for a database to hold pending transactions in
> memory. It's insane, it has to write the data
> anyway.
>
> Should you be concerned how much memory your
> processes take? Of course, but the database won't be
> your smoking gun and neither will the EJB transaction
> subsystem. It doesn't "remember" anything either.
>
> Most problems with long running transactions in EJB
> systems revolve around network connection timeouts
> from clients. EJB Timers don't suffer that problem
> since they're local to the container (unless they
> themselves are network clients, for example calling a
> long running remote EJB session bean).
>
Problem is related not with db, but default JPA implementation for glassfish. Toplink essentials is one to blame for huge memory consumption. Of-course it's possible to change to another implementation like Open JPA or Hibernate, but still it's better to warn person what kind of problems he will have to deal with.
> > Development of batch processing tasks on glassfish
> > was problematic and I got a lot of headache and
> > sleepless nights, but at the end it works very
> well
> > and I'm happy how stable and reliable it's.
>
> I'm glad he's happy with his Spring solution, but I'm
> very interested in more specifics about what his
> issues were.
I'm not happy with Spring-batch. I'm even don't use it. But I know it could be better solution. When I started to do batch processing job on Java EE with Glassfish, nobody warned me and nobody advised for best possible solution.
My point is, please give best possible solution you can, don't use you loved technology for everything. Be honest by helping to person, not to technology.
|
|
|
|
|
|
|
|
|
Re: Running Java Applications as a back-end batch processes
Posted:
Jul 15, 2008 9:33 PM
in response to: e3amir
|
|
|
Personally, I use Quartz (http://www.opensymphony.com/quartz/). I have a servlet that is initialized when my app starts up. The servlet sets up my schedules and starts up the scheduler. It has worked well for me. The only problem I have is when trying to shutdown the app server while doing a long-running job. Since Quartz uses its own thread pool, there are occasionally times when I have to forcibly stop Glassfish.
|
|
|
|
|
|
|
|
|
Re: Running Java Applications as a back-end batch processes
Posted:
Jul 16, 2008 8:27 AM
in response to: trekkyleaper
|
|
|
Hello,
We had similar requirement....infact we run over 7000+ batch jobs daily.
We had other requirements which quartz did not satisify - like dynamically inserting jobs, specifying / changing job criteria, inserting jobs in different timezones, putting jobs on hold, off hold, force terminate etc .
Quartz did not provide all these features...so we developed our own schedular (java + perl).
Ejaz
|
|
|
|
|
|
|
|
|
Re: Running Java Applications as a back-end batch processes
Posted:
Jul 16, 2008 8:36 AM
in response to: mohdejaz
|
|
|
Plus we were required to execute shell scripts ....show process id ...all without using JDBC ....this is much more like Autosys like job schedular.
Ejaz
|
|
|
|
|
java.net RSS
