I've been doing some research(here and here and etc.) and with some experience I have follwing feeling about the choice between the two, it seems like:
CachingConnectionFactory is for simple container that don't have much of messaging transaction management(like Tomcat with ActiveMQ), so that the caching part can guarantee some level of performance even if Spring by nature have to start a new session/connection/producer to each transmission, so the same connection/session get cached to reuse and avoid overhead by extending SingleConnectionFactory.
DelegatingConnectionFactory is for mature application server so that the CF/transaction management is in the hand of the server(Websphere MQ, JBoss HornetQ etc) so that this CF plays as a delegation and leaves the workload to the server. So the actual performance depends on how to tune up app server's CF and queue and transaction management.
I may be too drunk to make this up so please correct me if above does not make sense. I have one more question base on this comparison that, if Spring JmsTemplate by nature have to open/close session and all to each transmission, then how we can improve the performance by utilize the JmsTemplate with the app server's jms management?
Related
Spring + Apache Kafka noob here. I'm wondering if its advisable to run a single Spring Boot application that handles both producing messages as well as consuming messages.
A lot of the applications I've seen using Kafka lately usually have one separate application send/emit the message to a Kafka topic, and another one that consumes/processes the message from that topic. For larger applications, I can see a case for separate producer and consumer applications, but what about smaller ones?
For example: I'm a simple app that processes HTTP requests => send requests to a third party service, but to ensure retryability, I put the request on a Kafka queue with a service using the #Retryable annotation?
And what other considerations might come into play since it would be on the Spring framework?
Note: As your question states, what'll say is more of an advice based on my beliefs and experience rather than some absolute truth written in stone.
Your use case seems more like a proxy than an actual application with business logic. You should make sure that making this an asynchronous service makes sense - maybe it's good enough to simply hold the connection until you get a response from the 3p, and let your client handle retries if you get an error - of course, you can also retry until some timeout.
This would avoid common asynchronous issues such as making your client need to poll or have a webhook in order to get a result, or making sure a record still makes sense to be processed after a lot of time has elapsed after an outage or a high consumer lag.
If your client doesn't care about the result as long as it gets done, and you don't expect high-throughput on either side, a single Spring Boot application should be enough for handling both producer and consumer sides - while also keeping it simple.
If you do expect high throughput, I'd look into building a WebFlux based application with the reactor-kafka library - high throughput proxies are an excellent use case for reactive applications.
Another option would be having a simple serverless function that handles the http requests and produces the records, and a standard Spring Boot application to consume them.
TBH, I don't see a use case where having two full-fledged java applications to handle a proxy duty would pay off, unless maybe you have a really sound infrastructure to easily manage them that it doesn't make a difference having two applications instead of one and using more resources is not an issue.
Actually, if you expect really high traffic and a serverless function wouldn't work, or maybe you want to stick to Java-based solutions, then you could have a simple WebFlux-based application to handle the http requests and send the messages, and a standard Spring Boot or another WebFlux application to handle consumption. This way you'd be able to scale up the former in order to accommodate the high traffic, and independently scale the later in correspondence with your performance requirements.
As for the retry part, if you stick to non-reactive Spring Kafka applications, you might want to look into the non-blocking retries feature from Spring Kafka. This will enable your consumer application to process other records while waiting to retry a failed one - the #Retryable approach is deprecated in favor of DefaultErrorHandler and both will block consumption while waiting.
Note that with that you lose ordering guarantees, so use it only if the order the requests are processed is not important.
Is there an equivalent to the ActiveMQ 5 PooledConnectionFactory for Artemis? Why is it available in one and not the other?
Spring, for example, offers a generic CachingConnectionFactory. This is great, but it implements the SingleConnectionFactory and only "pools" one connection.
It would be key to have a similar mechanism in the Artemis client that actually pooled greater than one connections.
Another thought is that maybe it's not implemented because a single connection supports concurrent sessions! I haven't tested the performance of a using a new connection per session. Is the performance the same or similar?
The PooledConnectionFactory in the ActiveMQ 5.x code-base is generic and can actually be used with ActiveMQ Artemis so there was no reason to port it into the Artemis code-base. That said, the JMS connection pool implementation has been pulled out of the ActiveMQ 5.x code-base, cleaned up, modified to support JMS 2, and made available here.
I'm not clear on what you mean by "concurrent sessions." Do you mean that the connection supports concurrently creating session or that the sessions themselves support concurrent use? The former is supported, but the latter is not.
In terms of performance, you'd have to benchmark your specific use-case. There are too many variables to simply say one is better than the other.
We are creating new application, which is going to use IBM's MQ as a JMS provider for a short term and switch to Tibco EMS within a year.
My question is how involving the changes would be from the Application code perspective.
So far reading from JMS documentation, my impression is it should only require minimal changes. Does anyone have experience with it and provide some input on the work involved in switching between JMS provider.
I've done POCs where I swapped out connection factories and used WMQ JMS Classes to send to various providers (TIBCO, ActiveMQ, etc), to prove out the interchangeability. I've also done full swaps from one vendors JMS to another. In theory, it should be very simple.
The biggest change will be with the connection factories. Everything JMS specific will be the same between providers. The more tightly coupled the code is to the connection factories, the more complex it will be to change the app itself. Outside of this, you may need to change vendor specific implementation of objects, such as MQQueue vs Queue.
One addition thing to keep in mid is dependent on the IBM endpoints. If you are using "target queue managers" on any producers, these will need to change. WMQ has a specific URI to reach queues on specific Queue Managers in a cluster ( "queue://target_qm/queue_name/" ). If any application uses this URI it will need to ensure it makes the proper changes here as well.
I have an application that consumes messages from a JMS topic. As part of the normal application flow it needs to periodically cease consumption of messages. While the application is in this state new messages are stored in the topic (note that my application is still running). Later the application resumes message consumption, also receiving those messages that were placed on the topic while the application wasn't listening.
This functionality is currently achieved by creating and disposing of connections from a ConnectionFactory. However, I now wish to migrate the application to Spring JMS. Although Spring rather neatly abstracts away much of the JMS boiler-plate - I no longer appear to have fine grained control over the underlying connection and hence cannot halt message consumption on demand.
Before I try to wade through Spring JMS internals, can anyone suggest a neat way of doing this?
Can you just avoid returning from onMessage()? How long do you want to stop consumption? Is your problem similar to https://stackoverflow.com/a/628337/20734
our needs for a queuing solution are fairly simple, a producer needs to put things in a persistent queue and these need to be handled by a consumer. The queuing systems needs to be integrated within a Spring application and distributed on multiple tomcat hosts.
When reading through questions i see a lot of people that warn about using ActiveMQ with Spring for example so i am wondering what the alternatives are when taking simplicity, scalability and performance in mind when combined with a Spring based application.
If you are already using Sping, then integrating ActiveMQ with it is fairly easy. The simplest solution would be to run ActiceMQ standalone and have your Tomcat applications simply communicate with it using Spring JMS (or AMQ client APIs)...
Another option is to use Apache Camel. It has great ActiveMQ support, can work with an external or embedded broker, adds many messaging/routing features and can be deployed standlone, in ActiveMQ or in Tomcat easily...good luck