We are using jms outbound channel adapter to send messages coming to one channel. For that we are accessing connection factory and queue using jndi template. Both config are using cache=true in their config.
But what we have noticed is that, for every message it sends, a new connection is being created instead of using from cache.
I believe behind the scene this outbound channel adapter uses "JmsSendingMessageHandler " which internally use jms template to send the message.
Can someone throw some light on how can we cache weblogic jms connection?
accessing connection factory and queue using jndi template
Caching in this context means caching the connection factory object, not its connection(s).
As long as you are not using JTA transactions, you can wrap the CF you obtain from JNDI into a CachingConnectionFactory. With JTA, the app server might need you to get a new connection for each TX and you will need to configure caching in the app server (if available).
Related
I am trying to implement the Azure service bus with help of java to receive messages from the queue but I am unable to connect to the service bus because of a proxy, I am getting a connection time exception i.e.
Microsoft.azure.servicebus.primitives.ServiceBusException: Error{condition=proton:io, description='Connection timed out: no further information', info=null}
and when I am trying it from my local network(without proxy) it is connecting to azure bus without any problem. I am using the same sample code which Microsoft has provided on GitHub i.e. QueuesWithProxy.java.
How to configure proxy for azure service bus using java?
I try to connect to Microsoft for this problem so I find out that the previous version of queue client supports ConnectivityMode using TCP, HTTP, HTTPS, and AutoDetect. ServiceBus Explorer is using AutoDetect, trying TCP first and then failing over to HTTPS, regardless of the transport mode we were using (SBMP or AMQP).
With the new client this has changed. TransportMode now combines both options and offers Amqp (AMQP over TCP) or AmqpWebSockets (AMQP over WebSockets). There's no AutoDetect mode. You will have to create your clients and specify TransportType as AmqpWebSockets to bypass blocked.
As we are not using stomp for our websocket server, spring doesn't offer message broker framework. My vision is to use spring messaging pub/sub with Redis message store for dev and migrate message broker from Redis to SQS+Dynamo for prod version.
As I exclude (since ios & Android not ready to put stomp client infront due to lack of support) Stomp, spring websocket library doesn't enable pub/sub function as well.
Our Business case example:
Every connected websocket session will initiate request to another microservice (which is a Java websocket client) to get data. My vision is to connect these two service through pub/sub architecture with redis.
Mobile client sends -> "Hi, Is my bill paid?" through websocket.
Websocket server receive this message and pass it to websocket
client service through redis pub/sub.
As websocket server and Websocket client are connected via Redi
pub/sub. They can exchange messages.
Websocket client will be connected to human agents system via socket
and pass "Hi, Is my bill paid?".
The response ("Yes, it is paid.") will be again published to
websocket server.
Websocket server will send it back to specific user destination.
Due to business reason we would like to keep 2 services for this use case. Websocket client can connect to customer agent system and its decoupled from our business logic.
Our mobile apps will speak to our own websocket server. This gives us a flexibility to add more customization and independent from a specific vendor.
Here is my workaround
Use spring-websocket without stomp to create Websocket server.
Use spring-Integration to create messaging architecture.
Every websocket session is bound to a spring integration channel and
send response to user specific destination.
Create a Redis request/response queue for every connection.
Spring integration channel subcribe to redis queue.
As our infrastructure doesn't offer Rabbit MQ support, Redis queue will be replaced by SQS in prod.
Question:
Can we create spring integration channels at runtime and bind to specific service or queue? Thought process is to offer one
channel per websocket session and delete channel when session ends.
Is there a better alternate solution available in spring integration or
spring messaging to execute this use case?
See the Java DSL Dynamic and Runtime Integration Flows.
You can register and destroy sub flows on-demand.
Keep a reference to the dynamically registered flow id and call remove() on the context.
Spring integration has built-in Websocket support based on Spring Framework's foundation.
Given the standard hybrid OnPrem/Cloud scenario where we have multiple OnPrem clients connecting to a service in the cloud, how can we service them all from a scaled out service (i.e. multiple listeners servicing multiple clients)?
Say we have a cloud service that implements the Hybrid Relay listener, and to service all of our clients we scale it out to N instances(up to 25). Clients get assigned to each instance via the documented load balancing feature so that each listener services a portion of the clients. What if we need to broadcast messages to all of the clients (like a chat application)? As far as I can tell, any single listener never has access to all of the client connections. Am I missing something?
I've used https://learn.microsoft.com/en-us/azure/service-bus-relay/relay-hybrid-connections-dotnet-get-started as an example to play around with this scenario by standing up multiple servers (listeners) with multiple clients (connections) connecting to each server, but there doesn't seem to be a way to broadcast or lookup ALL of the connections to the namespace, only the connections in the current listener scope.
but there doesn't seem to be a way to broadcast or lookup ALL of the connections to the namespace, only the connections in the current listener scope.
Message transfer of Azure Relay Hybrid is based on the connection. If a client is not connected to a server, we can't send message to the client from the server.
For the broadcast scenario, I suggest you use Azure Service Bus topics. After created a topic, you could subscribe this topic for all the clients. When we send a message to the topic, all the subscriptions will receive the message.
For how to use Azure Service Bus topics, link below is for your reference.
Get started with Service Bus topics(.NET)
I have created FTP polling using SPring Inetegration (FTP adaptors).Just like to know is there any known issues if i use in the loadbalancer. i.e we have our app deployed in 2 instance of server with LoadBalancer.
Just thinking if File is polled by one FTP Poller and processing and another FTP poller will again poll the same file and process?
For this purpose Spring Integration 3.0 has introduced FtpPersistentAcceptOnceFileListFilter
There is just need to use shared external Persistence MetadataStore - Redis or Gemfire.
Or implement your own, for example JDBC.
And contribute it to Spring Integration - https://jira.spring.io/browse/INT
I have a virtual machine on Azure which will listen to messages over the servicebus of Azure. And another developer needs to connect to this servicebus to send messages to my service. To do so, we need to come up with some protocol for this communication system. And I was thinking about using WSDL to make the server something webservice-like, but instead of listening to the standard HTTP ports it would connect to the service bus and within it a topic with subscription, or whatever. I'm still not sure what would be best.
So, is it possible? Has anyone done something similar before? Are there some examples?
Service Bus provides both Brokered and Relayed messaging models. With using Topics/Queues you are essentially sending and receiving message to/from the broker. So you can use APIs/protocols that the broker supports. As an example you can use the NetMessagingBinding from your service/client to send and receive messages through the queue. There is no contract here other than what you put in the BrokeredMessage body and properties values. The application on either end can decode/decipher that info as needed.
In the case of Relayed messaging however you are making a end-to-end connection between the client and the service with Service Bus serving as the proxy in-between for auth, location-transparency and even load-balancing. So here you can use from a variety of RelayBindings such as NetTcpRelayBinding or webHttpRelayBinding but then both the client and the service need to be available at the same time. Here you need the service and clients to be using the same contract.