I am working on a project where we are planning to use WLP (WebSphere liberty) instead of traditional WAS.
The code is using WAS scheduler for scheduling activities.
Does liberty also have the same level of support/features for scheduler as present in WAS .
How can I migrate the scheduler tasks from websphere to liberty?
Code using the Scheduler in traditional WebSphere Application Server should not be migrated to EE Concurrency Utilities unless you are certain that you do not need the transactional/persistent quality of service that the Scheduler provides (Scheduler tasks run in a transaction and can roll back and be retried, and they can also persist across server restart). To obtain a similar quality of service in Liberty, you should migrate your Scheduler tasks to Persistent EJB Timers. Note that while fail over support across multiple servers is not present in Persistent EJB Timers in Liberty at the time of writing this, it is currently being worked on.
Related
I am migrating application from WebSphere to liberty.
It uses WebSphere timer managers.
What is the use of timer manager?
Is this supported in liberty. Is it the same as timer service in liberty?
Liberty does not have TimerManager, but it has similarly capability for scheduling tasks via the EE Concurrency spec-defined javax.enterprise.concurrent.ManagedScheduledExecutorService, which is provided by the Liberty concurrent-1.0 feature. A knowledge center page includes some examples and describes how to configure. Another knowledge center page provides helpful information on migrating to EE Concurrency from CommonJ or AsyncBeans.
To answer you question about the difference between timer manager and timer service, timer service typically refers to the EJB Timer Service, which has a mechanism to schedule persistent and non-persistent timers. EJB non-persistent timers are another alternative in Liberty to the CommonJ TimerManager, if you happen to be using EJBs. Otherwise, ManagedScheduledExecutorService can be used regardless of whether or not you use EJBs. Both provide mechanisms for scheduling timers/tasks for execution in the future, where the timers/tasks do not persist across server start and do not have the ability to be rolled back and retried (those are additional value that is provided by EJB persistent timers).
Is there any way to schedule and monitor spring batch using IBM workload scheduler.
If your application exposes REST APIs, the easiest solution is to use RESTful job type running on dynamic or zcentric agent, the job connects remotely to the REST API, so the agent can run on a separate machine or container.
We are designing a solution that will consume messages from IBM MQ using JMS. The plan is to use WAS Liberty, so JMS is the technology of choice. We will create Message-Drive beans that will listen for messages in MQ queues.
We are considering both WAS Liberty and OpenLiberty as well.
The trick here is that we must implement it with fail-over, so that if one of our server fail, the other will keep consuming messages from MQ automatically. Like in a ative/passive mechanism.
I'm aware that the MQ adapter needs to be installed as it is not provided out-of-the-box.
I have the following questions:
Does WAS Liberty messaging implementation supports fail-over? Meaning that if the ative message consumer node fails, the stand-by node will automatically migrate and start consuming messages from MQ? What about OpenLiberty?
How can I configure the message system to work that way? Can you point out to the documentation?
Or is this feature only provided by WebSphere?
There is no such functionality in WebSphere Liberty or Open Liberty yet. You can create RFE here https://www.ibm.com/developerworks/rfe/?PROD_ID=544 .
There are ways to do it manually, check these links:
JMS Activation spec on Liberty: “WAS_EndpointInitialState” full profile equivalent property?
Controlling the state of endpoints at runtime
Solution that you could do:
create a script/application that will monitor your servers and call that API to enable/disable endpoint in specific server
or use Dynamic cluster/ auto scaling feature of Liberty and divide you app to two clusters - one with MDBs, one without. And then define policy that MDBs cluster has 1 instance always available. So once the server dies it is automatically restarted somewhere in the cluster
or use Kubernetes/ICP platform in the same way - so deploying 2 versions of app, and defining different replicasets parameters.
We are planning to retire the existing legacy java batch applications and recreate it with the latest available batch framework.
Given that we have a large number of batch jobs to be modernised, we are looking for a framework or architecture that would allow us to
Develop a batch solution that would allow us to dynamically deploy a new batch as and when they are created, without disturbing the existing deployed applications. - Does Spring cloud Task provide any of this feature. Note: We are looking only to deploy the apps to our local server, and has nothing to do with cloud.
If Spring Batch/Boot can provide us the feature we typically expect from a batch application, what is the special value add to go for Spring Cloud Task? - I wasn't able to completely understand this from the Spring documentation available online.
From the documentation of the Spring Cloud Task, I was able to understand that it allows an application to have many tasks within it. What should I do if each of the tasks have their own library dependencies, which might contradict with the dependencies of other Tasks? So in that case, should each of these tasks moved to a new application or this there a work around for that?
To answer your questions:
Does Spring Cloud Task handle orchestration - No. Spring Cloud Task does not handle orchestration of tasks or jobs. The component in this ecosystem that handles the deployment/orchestration of tasks or jobs is really Spring Cloud Data Flow (which is why I asked if you use any type of cloud platform including YARN, Cloud Foundry, Kubernetes, or Mesos...the environments supported by Spring Cloud Data Flow).
What added value does Spring Cloud Task provide over Spring Boot/Spring Batch - Spring Cloud Task is designed to provide a few things:
Similar abilities to Spring Batch with regards to state management without needing to create a batch job. When running a Boot application on a cloud environment, there is no standard way of getting the results from environment to environment (YARN handles job results differently from tasks on Cloud Foundry which is different from jobs on Kubernetes, etc). Spring Batch provides this but now all short lived processes need the overhead of the Batch API so Spring Cloud Task provides a lighter touch to those use cases.
Automatically adds informational listeners. With Spring XD, when you ran a job in an XD container, the XD container automatically added a number of informational listeners that broadcast events that you could listen for. Spring Cloud Task brings the same functionality without the need for the XD container.
Integration with Spring Cloud Stream. Spring Cloud Task provides the ability to launch tasks from messages received from Spring Cloud Stream. Also, the informational messages previously mentioned (both Batch events as well as Task events) are sent via Spring Cloud Stream channels.
The DeployerPartitionHandler. When working in a cloud environment, this PartitionHandler implementation allows you to launch workers for a partitioned batch job as tasks. This allows for the dynamic scaling of partitioned batch jobs instead of the traditional option of pre-deploying workers that listen for work which wastes resources in a modern cloud environment.
How does the packaging of multiple tasks work with dependencies - In short, this is not recommended. The idea of a Spring Cloud Task is that the execution of the Spring Boot application is the Task. While you could package up multiple tasks and using different methods, have them execute based on different stimulus, that goes against the 12 factor application concepts which are essential for correct use of Spring Cloud Task.
My two cents
For the best option for a modern batch platform, you really need to look into some from of platform first and that begins at the Cloud Foundry/Kubernetes/Mesos/YARN layer. Without that, you end up building a large part of the infrastructure yourself. That is why Spring XD evolved into Spring Cloud Data Flow. The added complexity that lived in the containers of Spring XD is removed by requiring a modern platform to run on (since they all handle those guarantees themselves). Without that piece, you're going to spend a lot of time managing the deployment and orchestration of applications that most modern platforms handle for you.
From there, the choice becomes pretty easy IMHO with Spring Cloud Task for simple tasks, Spring Batch for batch jobs, and Spring Cloud Data Flow for orchestration.
Could you run Spring Batch inside a Java EE server (eg. WebLogic), let's say as a Web Application? Is there any issue with Spring Batch creating more threads (for multi threaded steps and parallel steps) inside a Java EE server? Is this creation of threads by the framework against Java EE specification?
I am thinking it is okay and people are doing this after reading the following link
http://static.springsource.org/spring-batch/reference/html-single/index.html#runningJobsFromWebContainer
Please help.
This is an old question, but I will add an answer after all.
Yes, there may be some problems. I encountered such problems on WebSphere server.
According to their documentation: http://www-01.ibm.com/support/docview.wss?uid=swg21246676
Using a Java™ call such as "newThread()" to spawn a new thread is not
supported according to the J2EE specification. This spawned thread
does not inherit the J2EE context. What is recommended to do instead
is to use an asynchronous bean or Commonj WorkManager thread. These
threads have a proper J2EE context and support an indirect JNDI
lookup.
Spring batch creates it's own threads using new Thread, and these threads do not inherit J2EE context.
In my specific case one of Spring Batch Job consumed a few REST services over https, and it turned out that threads spawned by Spring Batch don't see https cerificates installed in WebSphere server, causing certificate's errors.
I see no issue here.
Spring Batch (like Quartz Scheduler) runs as a Web Application, it is not bound by the prohibition to create threads, which applies only to EJB components (not to Servlets).
So, provided you do not exceed the server capacity limits, Spring Batch can run in any EE application.
It is a common practice. The book Spring Batch In Action Chapter 4.4 discusses the exact same scenario, launching the batch job from the web container. The batch job should be run within a thread pool with N threads. The number of threads in the pool should be determined by the throughput result of performance load test.