[activemq-user] How many JDBC connections does ActiveMQ use?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[activemq-user] How many JDBC connections does ActiveMQ use?

Jeff Sparkes
We've got a situation with a database server that has too many
connections bogging it down.
Someone has pointed at ActiveMQ as a possible culprit, invoking the
"somebody else did it" principle.

From my reading of
/modules/core/src/java/org/activemq/store/jdbc/TransactionContext.java
it seems that there is only one connection open at a time per thread.
Multiple statements
are executed during the same connection for efficiency.  The javadoc
for pushConnection()
implies that nesting is possible, but apparently it's not implemented
yet.  It would be easy
to make an array of size larger than size 1, or an ArrayList.  I guess
that the need hasn't arisen yet.

The standard configuration, and mine, only has one Durable Queue
Worker thread, so I
assume that there's only one thread, and thus only one JDBC connection
open at a time.
(Is it even possible to configure more worker threads?  Not that I
need them, ActiveMQ doesn't
figure into our performance hotspots.)

Can any confirm that there's only one JDBC connection at a time, or
explain why I'm wrong?
To quote Denzel Washington's character in Philadelphia: "Explain it to
me like I'm a five year
old".

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] How many JDBC connections does ActiveMQ use?

chirino
Hi Jeff,

Depends on it's use.  If the JDBC adapter is being used without the  
journal, then there could be 1 connection per concurrent message send  
and message acknowledge + 1 (for the database clean update process).  
But since most DataSources pool connections they allow you to set a  
max number of created connections.

If the adapter is being used with a journal, then the jdbc connection  
is only used when checkpointing is occurring and usually it's 1  
concurrent connection per destination in activemq 4.

Regards,
Hiram

On Nov 28, 2005, at 2:48 PM, Jeff Sparkes wrote:

> We've got a situation with a database server that has too many
> connections bogging it down.
> Someone has pointed at ActiveMQ as a possible culprit, invoking the
> "somebody else did it" principle.
>
>> From my reading of
> /modules/core/src/java/org/activemq/store/jdbc/TransactionContext.java
> it seems that there is only one connection open at a time per thread.
> Multiple statements
> are executed during the same connection for efficiency.  The javadoc
> for pushConnection()
> implies that nesting is possible, but apparently it's not implemented
> yet.  It would be easy
> to make an array of size larger than size 1, or an ArrayList.  I guess
> that the need hasn't arisen yet.
>
> The standard configuration, and mine, only has one Durable Queue
> Worker thread, so I
> assume that there's only one thread, and thus only one JDBC connection
> open at a time.
> (Is it even possible to configure more worker threads?  Not that I
> need them, ActiveMQ doesn't
> figure into our performance hotspots.)
>
> Can any confirm that there's only one JDBC connection at a time, or
> explain why I'm wrong?
> To quote Denzel Washington's character in Philadelphia: "Explain it to
> me like I'm a five year
> old".
>
> Thanks.

Reply | Threaded
Open this post in threaded view
|

[activemq-user] Did you solve problem multipart messages set to Temp Queue across Network Of Brokers in rel 4.0 M2?

gklyuzner
In reply to this post by Jeff Sparkes
Did you solve problem multipart messages set to Temp Queue across  Network Of Brokers in rel 4.0 M2?
in rel 3.1 M6 it was not reliable.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The information contained in this email is confidential and may also contain privileged information. Sender does not waive confidentiality or legal privilege. If you are not the intended recipient please notify the sender immediately; you should not retain this message or disclose its content to anyone.
Internet communications are not secure or error free and the sender does not accept any liability for the content of the email. Although emails are routinely screened for viruses, the sender does not accept responsibility for any damage caused. Replies to this email may be monitored.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

[activemq-user] Did you solve the problem with multipart messages sent to Temp Queue across Network Of Brokers in rel 4.0 M2?

gklyuzner
In reply to this post by Jeff Sparkes
Did you solve the problem with multipart messages sent to Temp Queue across  Network Of Brokers in rel 4.0 M2? Some parts got lost during transition. messages > 64Kb.

Sorry, previous email had a Typo.

-----Original Message-----
From: Klyuzner, Glen [mailto:[hidden email]]
Sent: Monday, November 28, 2005 6:52 PM
To: [hidden email]
Subject: [activemq-user] Did you solve problem multipart messages set to
Temp Queue across Network Of Brokers in rel 4.0 M2?


Did you solve problem multipart messages set to Temp Queue across  Network Of Brokers in rel 4.0 M2?
in rel 3.1 M6 it was not reliable.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The information contained in this email is confidential and may also contain privileged information. Sender does not waive confidentiality or legal privilege. If you are not the intended recipient please notify the sender immediately; you should not retain this message or disclose its content to anyone.
Internet communications are not secure or error free and the sender does not accept any liability for the content of the email. Although emails are routinely screened for viruses, the sender does not accept responsibility for any damage caused. Replies to this email may be monitored.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The information contained in this email is confidential and may also contain privileged information. Sender does not waive confidentiality or legal privilege. If you are not the intended recipient please notify the sender immediately; you should not retain this message or disclose its content to anyone.
Internet communications are not secure or error free and the sender does not accept any liability for the content of the email. Although emails are routinely screened for viruses, the sender does not accept responsibility for any damage caused. Replies to this email may be monitored.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------