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).
Related
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.
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.
This article indicates that if MQ has to be used as a Transaction Manager, the application has to compulsorily use Bindings mode.
http://www.ibm.com/developerworks/websphere/library/techarticles/0601_ritchie/0601_ritchie.html
Bindings mode also means that the MQ Server and the application both have to be on the same host because it uses JNI.
My question is, what is the fundamental reason behind this requirement? Why can't MQ Manager work like JBOSS which can reside on any host and take requests for managing distributed transactions?
What prevents WMQ from supporting client connection for distributed transactions?
Thanks,
Yash
That article is very old, it was from 2006, for a long time now MQ clients that are located remote from a queue manager have been able to use XA transactions.
MQ supports XA with JMS when using a supported transaction manager within a JEE container
http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q032590_.htm?lang=en
I have few basic douts.
I have developed a JMS application for P-P and the messages are geeting stored in Jboss 7.1 JMS engine. My questions are below.
1.For any JMS application do we need to have any messaging engine like IBM MQ,HornetQ,Active MQ etc
If Yes then we need to configure the MQ to atlk to Appserver Messaging engine.
3.If No, Then we need to have to create a message consumer
JMS is a specification of a messaging interface - and a state model for how messages are handled in transactions.
jms.jar contains pretty much all interfaces - no implementations. Therefore whilst you can write an application against jms.jar you can't actually run it.
You'll need to pick some type of messaging provider. That's appropriate to your requirements.
That's not a discussion for here however keep in mind that they each have possible extensions and functional behavior outside of the specification so if you want to be portable between providers pay close attention to only use specification defined functionality.
Within a JavaEE Application Server there will be a JMS implementation that provides messaging features. Therefore an app here in JBOSS will be a MOM (messaging oridentated middleware) application. If you want the message to be accessed by an application not running in a JavaEE server then that is possible with some providers. There's often a JavaEE client container. Or the messaging engine will have a JavaSE based client that can be used. (WAS thin client client for example).
Remember that with JavaEE servers you are not restricted to a the choice of messaging provider - you can use the JCA interface to directly plug in a external messagin implementation. This might present an easier route if a lot of messaging will be outside the JavaEE server.
EDIT - added JavaEE notes
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.