-
1. Re: Jboss7, 2.2.13 hornetq- createConnection takes a long time unless using a cached HornetQConnectionFactory
jbertram Jan 4, 2013 5:51 PM (in response to kperry)I can't think of anything which might have changed in HornetQ recently that would increase the time taken to create a connection, but I can certainly say that creating a connection every time you need to send or receive a message is a huge antipattern. Connections are "heavy" and are meant to be re-used.
-
2. Re: Jboss7, 2.2.13 hornetq- createConnection takes a long time unless using a cached HornetQConnectionFactory
kperry Jan 4, 2013 6:05 PM (in response to jbertram)I am confused. Doesn't this site: https://community.jboss.org/wiki/ShouldICacheJMSConnectionsAndJMSSessions say that if you code is running in a JEE application server than you don't need to worry about it?
-
3. Re: Jboss7, 2.2.13 hornetq- createConnection takes a long time unless using a cached HornetQConnectionFactory
ataylor Jan 5, 2013 4:56 AM (in response to kperry)your connection probably takes a while because you are using discovery.
regarding the article and caching connections, you need to use the correct connection factory for this, java:/JmsXA in as5/6 or a pooled connection factory in AS7
-
4. Re: Jboss7, 2.2.13 hornetq- createConnection takes a long time unless using a cached HornetQConnectionFactory
kperry Jan 7, 2013 12:10 PM (in response to ataylor)Thanks for the responses. Any idea why a cached hornetqConnectionFactory has better createConnection() performance? It makes no sense to me and seems to be a bug. Are there any implications to using a cached connectionFactory?
In our case we are using a request response pattern with temporary queues (which are expensive already) so the JbossWs1 box is a producer and consumer to/from remote queues on JbossJMS1 and JbossJMS2. If using a pooled connection factory in AS7, can you give more detail on how that is setup . I have a couple of concerns about this article: https://docs.jboss.org/author/display/AS72/Messaging+configuration
It states the following - I bolded my concerns:
There is also a pooled-connection-factory which is special in that it leverages the outbound adapter of the HornetQ JCA Resource Adapter. It is also special because:
- It is only available to local clients, although it can be configured to point to a remote server.
- As the name suggests, it is pooled and therefore provides superior performance to the clients which are able to use it. The pool size can be configured via the max-pool-size and min-pool-size attributes.
- It should only be used to send (i.e. produce) messages.
- It can be configured to use specific security credentials via the user and password attributes. This is useful if the remote server to which it is pointing is secured.
- Resources acquired from it will be automatically enlisted any on-going JTA transaction. If you want to send a message from an EJB using CMT then this is likely the connection factory you want to use so the send operation will be atomically committed along with the rest of the EJB's transaction operations.
Also, while I realize that creating the connection is heavy, but using the cached hornetqConnectionFactory it is a fraction of a half-second....and we can afford that. We can't afford the slow 700ms to 7 second behavior that we were seeing without the caching of the connectionFactory.
-
5. Re: Jboss7, 2.2.13 hornetq- createConnection takes a long time unless using a cached HornetQConnectionFactory
ataylor Jan 8, 2013 3:11 AM (in response to kperry)The reason cahed connection factory is quicker is because it reuses the connections as they are pooled, it is in spring to avoid the cost and use of the anti pattern of creating a new connection every time. However a i mentioned before, the reason it takes so long in the first place is because you are using discovery, use a static address and it will be much quicker.
It is only available to local clients, although it can be configured to point to a remote server.
Yes, this is part of JEE and is managed by the application server and should always be used when in an application server environment.
It should only be used to send (i.e. produce) messages.
again this is part of JEE and you should not block application server threads by doing a receive, instead you should use an MDB