How much is the overhead of creating following objects everytime sending the message to queue?
Objects: javax.jms.Connection, javax.jms.Session, javax.jms.MessageProducer
In my code, Whenever I want to send a message, I am creating above 3 objects.
I know its good to create object only once and use it but the connection/session goes into IllegalState after Server Failover. My connectionFactory is able to reconnect but it is not able to refresh connection/session object.
Can someone please explain me the overhead?
https://developer.jboss.org/wiki/ShouldICacheJMSConnectionsAndJMSSessions
High Performance JMS Messaging
:)
It is always a costly affair to create a connection and session to a messaging provider every time. Every time a connection is requested, the underlying messaging library has to create a socket connection to messaging provider, flow some handshake data and establish a channel using which messages can be sent. After message is sent, connection close also requires some messaging provider specific data to be sent across to gracefully close connections.
You can quantify the overhead by running some tests with and without creating connections/session every time. But the above explanation gives a hint on what would be involved in creating/closing a connection.
Related
The problem: I'm having some packet loss internally. I mean internally because did capture all the traffic with wireshark and confirm the packet arrived at server, but did not arrive at channelRead0 method.
Scenario:
I built a SIP Server using Netty. The system uses UDP to communicate with other sip endpoints and works fine at low load.
My doubt is about design. Since SIP is a session protocol, on every packet received, I need to check what session it belongs to. The heavy workload surely is on the synchronized list that holds all sessions (I know need to optimize this on the future).
The whole system logic is inside channelRead0 method and this probably is the reason i'm losing some packets. The problem start to happens at around 500 pkt/sec.
There is no database connection (yet), the only I/O is writing log to a file which has almost no impact.
The question: How should I proper design this to handle 5000 pkts/sec? Maybe put all packets in a synchronized queue and handle them later?
Thanks for all help
I'm using Paho to communicate with an MQTT broker and all the example I found (like this) do these 3 steps when performing an action (publish or subscribe):
connect to the broker
do action
disconnect
My question is: are there any drawbacks holding a connection for the whole life of the application instead of opening/closing it for each action? Isn't it a faster solution removing the time for opening the connection?
No, holding a connection open for the lifetime of the application is a fully expected usecase, it's the only real way you'd be able to subscribe to a topic and receive messages when they are published.
The protocol has built in ping messages to ensure the broker knows the client is still connected.
The examples tend to be relatively trivial but want to show the full life cycle of the client which is why they connect, do something, disconnect
I understand JMS as depicted by the following diagram:
(source: techhive.com)
Is there any way for me to access the underlying database using JMS or some other thing? Further, the JDBC connections that the JMS server maintains, can I add new connections in it so as to access other databases also and do CRUD operations on them? If yes, how?
Where did you get this from?
Normally JMS is used to send messages to queue (or topics). You have message producers that push messages in the queue and message consumers consume them and process it.
In your exemple it seems that you have multiple queues. One for the messages that need to be processed, and one for each client to retrieve the result the processing of its messages.
With JMS Server you don't necessarily have a database behind. Everything can stay in memory, or can be written to files. You will need database server behind only if you configure your JMS server to be persistent (and to assure that even if server/application crash your messages won't be lost). But in that case you will never have to interact with the database. Only the JMS server will and you will interact with the JMS server sending and consuming messages.
I need to send a continuous flow of messages (simple TextMessages with a timestamp and x/y coordinates) over a wireless network from a moving computer. There will be a lot of these short messages (like 200 per sec) and unfortunately the network connection is most likely unreliable since the sending device will leave the WLAN area from time to time... When the connection is not available, all upcoming messages should be buffered until the connection is back up again. The order of the transmitted messages does not matter, since they contain a timestamp, but ALL messages must be transferred.
What would be a simple but reliable method for sending these telegrams? Would it be possible to just use a "plain" TCP or UDP socket connection? Would messages be buffered when the connection is temporarily down and send afterwards automatically? Or is the connection loss directly detected and reported, thus I could buffer the messages and try to reconnect periodically on my own? Do libraries like Netty help here?
I also thought about using a broker to broker communication (e.g. ActiveMQ network of brokers) as an alternative. Would the overhead too big here?! Would you suggest another messaging middleware in this case?
TCP is guaranteed delivery (When it's connected that is) - You should check if the connection went down and put messages in a queue while it is retrying the connection. Once it sees that connection is back up dump the queue into the TCP socket.
Also look into TCP Keepalive for recognition of a down connection: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
Seems like you could use a message wrapper like Java JMS using a "Assured persistent" reliability mode. I have not done this myself, in the context of text messages, but this idea may lead you to the right answer. Also, there may be an Apache library already written that handles what you need, such as Qpid .
When there is a network problem which results in the client being disconnected from the JMS server, is there some other way to detect the problem other than waiting until the next JMS message being sent fails?
You can register an ExceptionListner with the JMS Connection using Connection.setExceptionListener(ExceptionListener)
The ExceptionListener will get notified of more problems than an actual disconnection, so you may have to filter the JMSException that gets passed to the listener.
ExceptionListener isn't necessarily enough. You also need to catch exceptions on any JMS calls you make (sending messages, for example). See Reconnecting JMS listener to JBossMQ
if your are running on MQ and looking to solve this problem, install a local MQ instance. More license but you will get guaranty delivery if your main corporate MQ goes down.
Other Option, use Spring and let the framework do the recovery of the connection.