Should a single connection object be used for all actions?

[maleck13]

Hey,

Just trying out this lib. Was curious whether the stomp connection should be created just once and reused for subscribing and publishing or whether a new one should be created per action. My assumption is to use a single connection for all application actions.

[gmallard]

On 03/27/2016 01:17 PM, Craig Brookes wrote:

Hey,

Just trying out this lib. Was curious whether the stomp connection
should be created just once and reused for subscribing and publishing
or whether a new one should be created per action. My assumption is to
use a single connection for all application actions.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#4

Hello Craig - I guess my naming conventions are not the best ...... and
do need some better documentation.

You can certainly use a single connection for everything you do - or not.

The examples ->

The srmgor_1conn subdirectory:

Send and Receive, multiple go routines, all senders/receiver goroutines
share a single network-and-Stompngo connection.

(I think you are suggesting this is your design choice.)

The _srmgor_1smrconn_subdirectory:

Send and Receive, multiple go routines, 1 sender/publisher network-and-
Stompngo connection, many network-and- Stompngo receiver/consumer
connections (1 connection per receiver goroutine).

The srmgor_2conn subdirectory:

Send and Receive, multiple go routines, two connections total, 1
network-and-Stompngo connection for all senders, 1 network-and-Stompngo
connection for all receivers.

The _srmgor_manyconn_subdirectory:

Send and Receive, multiple go routines, 1 network-and-Stompngo
connection for each sender goroutine, 1 network-and-Stompngo connection
for each receiver goroutine.

---

The stompngo package is implemented such that you can accomplish
whatever you need (at least I think that it is.).

However, in practice, you will find that your design choice has
performance implications. The best design choice depends on a number
of factors, including:

• client machine capabilities (CPUs, RAM, etc)
• server machine capabilities (CPUs, RAM, etc)
• the particular message server (ActiveMQ, Apollo, RabbitMQ, ...... MOM
  server of the day.)
• the client machine configuration (max open files and such)
• the message server configuration (max open files and such)
• the message payloads you expect: large messages, small messages,
  mixed length messages, etc. ........

As with all things performance related: I suggest you implement
prototypes for each choice, and benchmark.

It is hoped that all of the examples above can help you with the best
design choice for your particular application needs.

---

I hope all this is .... food for thought and will help you with the
design choice you make. I suggest you look at the comments at the
beginning of each example for further knowledge.

Please let me know if you have any questions.

Regards, Guy

[maleck13]

Hey,
Thanks very much for the great answer, I went for the single shared connection, and it is currently working great.