Julien Schreiber
2003-12-08 10:22:40 UTC
Hi,
I have a short question raised when I ran some tests in order to analyse the former problems (described below).
Can you confirm that the MOM where the messages are sent to corresponds to the IP address described in the MomServer.xml config file ?
Just to remind you about our problem : We are using 2 Moms running on 2 servers (hardware implementation).
What we saw during our tests is that the sender running on the first server seems to send messages on the remote Mom by using an interface that doesn't correspond to the IP address described in the MomServer.xml config file, but through an interface mentionned in the /etc/hosts file :
-> messages are sent on the address "172.26.47.14" , instead of 172.26.44.73
- bt1flocur21 is the "hostname" of the remote server
- We are using SUN V880 (Solaris 8.0)
****************************************
In the /etc/hosts file
172.26.47.14 bt1flocur21
****************************************
I have this configuration in the MomServer.xml file :
<!-- Optional. This represents the default configuration -->
<ServerConfiguration host="172.26.44.73" embeddedJNDI="true" />
****************************************
In our config file :
publiclocConfigGeneral.mom.1.host=172.26.44.73
publiclocConfigGeneral.mom.1.port=1099
****************************************
Here is the code we use to initialize our mom connections :
private Context getRmiContext() throws Exception {
/*
* connect to the JNDI server and get a reference to root context
*/
Hashtable props = new Hashtable();
// default value (to be passed in config files)
String jndiname = "JndiServer";
String mode = "rmi";
logger_.debug ("getRmiContext: host: " + host_ + ", jndiname:" + jndiname + ", mode: " + mode + ", port: " +port_);
String modeType = RmiJndiInitialContextFactory.class.getName();
/*
* put information regarding connection in the Hashtable
*/
props.put(Context.PROVIDER_URL, "rmi://" + host_ + ":" + port_ + "/" + jndiname);
props.put(Context.INITIAL_CONTEXT_FACTORY, modeType);
/*
* create context
*/
Context context = new InitialContext(props);
return context;
}
}
With host_ and port_ set with the values retrieved in our config file.
Thanks in advance for your help !
Julien
----- Original Message -----
From: Julien Schreiber
To: openjms-***@lists.sourceforge.net
Cc: 'Régis Lebrun'
Sent: Wednesday, November 19, 2003 12:06 PM
Subject: Re: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
Hi Jim,
Thanks for your answer.
I have a question relative to this solution :
- We would like to use NON_PERSISTANT messages to avoid using JDBM database. Do you think that forcing the messages not expiring at all (by configuring the TTL parameter as described above) will allow to treat messages that gathered a network problem : If the sender is running on a first server and the OpenJMS MOM is running on a remote server, if the message can't be sent because of a network problem, does the fact that the TTL is set to "0", "-1" or a longer value, make the sender keep the message in memory in order to resend ("replay") this message later ?
On the OpenJMS server side, if the listener is busy, is the message kept in memory until the listener is available to receive messages thanks to the configuration of the TTL param as "0", "-1" or longer value ?
Thanks in advance for these precisions !
Regards
Julien
----- Original Message -----
From: Jim Alateras
To: openjms-***@lists.sourceforge.net
Cc: 'Régis Lebrun'
Sent: Tuesday, November 18, 2003 8:41 PM
Subject: RE: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
Hi Jim,
thanks a lot for these precisions.
We are using Non-persistent messages. (but the openJms.db file is created and locked.)
*****************************
here is our configuration :
<?xml version="1.0"?>
<!-- OpenJMS configuration:
. TCP connectors
. JDBM persistency
. embedded JNDI provider
. preconfigured destinations
-->
<Configuration>
<!-- Optional. This represents the default configuration -->
<ServerConfiguration host="172.28.20.131" embeddedJNDI="true" />
<!-- Connector is TCP -->
<Connectors>
<Connector scheme="rmi">
<ConnectionFactories>
<QueueConnectionFactory name="JmsQueueConnectionFactory" />
</ConnectionFactories>
</Connector>
</Connectors>
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
<!-- Required -->
<AdminConfiguration
script="${openjms.home}/../../scripts/mom.sh -start"
config="${openjms.home}/../MomServer.xml" />
<!-- Optional. If not specified, no destinations will be created -->
<AdministeredDestinations>
<AdministeredQueue name="requestLocQueue" />
<AdministeredQueue name="locResultQueueA" />
<AdministeredQueue name="locResultQueueB" />
<AdministeredQueue name="isAliveQueue" />
</AdministeredDestinations>
</Configuration>
************************************************************
here is the source code we use to send messages :
String connectionFactoryName = "JmsQueueConnectionFactory" ;
QueueConnectionFactory connectionFactory = (QueueConnectionFactory)context.lookup(connectionFactoryName);
QueueConnection connection_ = connectionFactory.createQueueConnection();
connection_.setExceptionListener(new ExceptionListener());
connection_.start();
QueueSession session_ = connection_.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
//method called to send message in the MOM
public void send (Serializable object, String queueName) throws javax.jms.J
MSException {
Queue queue = (Queue)queueMap_.get (queueName);
QueueSender sender = session_.createSender(queue);
ObjectMessage message = session_.createObjectMessage();
message.setJMSDeliveryMode(DeliveryMode.NON_PERSISTENT);
message.setObject(object);
sender.send(message, DeliveryMode.NON_PERSISTENT, 1, 10000);
}
Here are my questions :
- do you think the parameters passed to the send method are correct ? TimeTolive=10000 and priority=1
there is no problem with the parameters. TTL is 10 seconds and priority is 1.
- Do you think that parameters of the ObjectMessage could be set uncorrectly ; for instance parameters such as JMSDestination, JMSExpiration, JMSTimeStamp, JMSMessageId. Normally these parameters are set automatically when the message is sent. But do you think that in the scope of our problem (messages lost when using a OpenJMS server running on a remote server) one of these parameters could be set badly. Is this possible ?
it may be a problem although I am relatively confident that this is not where your problem lies.
For instance what is the default value of the JMSExpiration parameter ? If a network problem exists that force the message to spend some time before reaching the remote OpenJMS Server (running on a remote server), is the message lost ?
default for expiration is LIVE_FOREVER (There are some additional constraints for topic message model). If the message is not delivered within 10 seconds then the OpenJMS server will not deliver it. Try using a longer ttl or set it to -1 or 0 (you need to check the JMS specification for the correct value) so that it doesn't expire at all.
Thanks a lot in advance for your help.
At the beginning, we thought that the JDBM database was the source of our problem. But perhaps this is our customization of the openJMS MOM that is not able to manage network problems that could occur between the 2 servers where the 2 MOM are running.
the problem is most likely related to the TTL value passed to sender.send
cheers
</jima>
Regards,
Julien
----- Original Message -----
From: Jim Alateras
To: openjms-***@lists.sourceforge.net
Cc: 'Régis Lebrun'
Sent: Monday, November 17, 2003 7:27 PM
Subject: RE: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
Hi Tim,
Since I have had no news from you since last wednesday, I contact you again regarding the problem we have with OpenJMS MOM 0.7.5.
Tim will be away for the until Wednesday.
Below are my previous questions. Once again, we are looking for a mean to customize the JDBM database, because we can't use RBDMS database in the scope of our project
You should be aware that we will stop supporting JDBM, if we haven't already so you need to look for an alternative (i.e. hsql)
My questions are :
- does our configuration explain our problems regarding messages lost when using 2 MOM on 2 servers (physical hardware implementation) ? (this problem is described below in my previous mails)
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
<!--
<DatabaseConfiguration garbageCollectionInterval="600"
garbageCollectionBlockSize="500"
garbageCollectionThreadPriority="5">
-->
- Is there a way to indicate that "No Garbage Collection should be used" ? Perhaps when we are running 2 Moms on 2 servers, some messages are deleted on one server while the other server have not received the messages yet...
try removing the all garbageXXXXX attributes in the DatabaseConfiguration element or set garbageCollection to '0'
- Do you think it is possible that the "remote" listener couldn't "retrieve" messages in the database ? Is it a problem of synchronism between 2 applications reading the same file (containing data) ?
can you elaborate?
- What happens when for One MOM running on a server (physical hardware implementation), the application that sends messages in the MOM is running on one Server and the listener is running on the other server (physical hardware implementation) ? Is the db file readable by the 2 applications ?
the db file is locked when the server is running so you can't run 2 OpenJMS server's pointing to the same openjms.db file (if that's what you're asking)
- what is the openJms.db file exactly used for ?
for persistent messages
Thanks in advance for your answers,
We have to give an answers by the end of the week
Regards,
Julien
----- Original Message -----
From: Julien Schreiber
To: openjms-***@lists.sourceforge.net
Cc: Régis Lebrun
Sent: Wednesday, November 12, 2003 2:01 PM
Subject: Re: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
Hi Tim,
thanks a lot for your answer and your precisions. ( Infact, we couldn't log in and read your first answer...)
The problem is that we can't use RBDMS database in the scope of our project. So we will have to customize the JDBM database.
- In our configuration file, there is only one parameter linked to the database configuration :
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
The other parameters are put as comments.
Do you think this configuration is enough ?
- Do you think that the lost of messages described in our previous messages :
" The problem is systematically reproduced when we use a listener on another server (physical hardware implementation) than the MOM
It is not due to a huge traffic.
We use server A and server B.
If we install the MOM on server A and the listener in server B, we have the problem (100 messages lost for 54 000 messages sent at a frequency of 5 messages per second)
if we install the MOM on server A and the listener also, we never have the problem in hte same load configuration.
What we think l is that it can be a socket lost that is badly managed by the MOM."
....can be explained by the use of the JDBM database (or by a bad configuration of the database in the config file ?)
Could you explain me what kind of messages are stored in the JDBM database ?
Do you think it is possible that the "remote" listener couldn't "retrieve" messages in the database ? Is it a problem of synchronism between 2 applications reading the same file (containing data) ?
Thanks in advance for your help !
Regards,
Julien
----- Original Message -----
From: Tim Anderson
To: openjms-***@lists.sourceforge.net
Sent: Wednesday, November 05, 2003 5:54 AM
Subject: RE: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
I responded to this a while ago: http://sourceforge.net/mailarchive/message.php?msg_id=6246957
The only thing I can add is that I don't think database garbage collection was working correctly in 0.7.5.
This is no longer needed, and has been removed in 0.7.6.
If you have it enabled, turn it off, by removing the garbageCollection* properties on
the <DatabaseConfiguration/> element in openjms.xml
-Tim
-----Original Message-----
From: openjms-developer-***@lists.sourceforge.net [mailto:openjms-developer-***@lists.sourceforge.net]On Behalf Of Julien Schreiber
Sent: Wednesday, 5 November 2003 1:48 AM
To: openjms-***@lists.sourceforge.net
Cc: Régis Lebrun
Subject: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
Hi,
Sorry if you have already received this mail. I just received a confirmation saying that I have joined successfully the Mailing list so I try to send it again...
Régis and I try to contact you for a problem occured on our OpenJMS MOM 0.7.5.
Our problem is described below...
Below is also an answer Jima gave us a few monthes ago concerning performances of the MOM. He answered about JDBM database. Do you think our problem could be linked to this ? Do you think the configuration of the MOM is correct ?
Thanks in advance to give us some help or any answer prouving that this email reached someone successfully !!
Kind regards,
Julien Schreiber
Cap Gemini Telecom France
----- Original Message -----
From: Régis LEBRUN
To: openjms-***@lists.sourceforge.net
Cc: Julien Schreiber
Sent: Thursday, October 09, 2003 5:06 PM
Subject: Fw: MOM replay management : OpenJMS MOM 0.7.5.
I received a mail error sending my email to my previews contacts on OpenJMS. I don't know why.
please find here after a brief description of our problem.
I hope you will be able to help us
Kind Regards
Régis Lebrun
----- Original Message -----
From: Régis LEBRUN
To: ***@intalio.com ; ***@intalio.com
Cc: Julien Schreiber
Sent: Thursday, October 09, 2003 5:23 PM
Subject: MOM replay management : OpenJMS MOM 0.7.5.
Hi,
Julien, a guy working in my team sent you an email last week. As we didn't receive any news from you and as the problem is quite important (lost of messages), I wanted to bring you some precisions. Please, we need a quick answer.
The problem is systematically reproduced when we use a listener on another server (physical hardware implementation) than the MOM
It is not due to a huge traffic.
We use server A and server B.
If we install the MOM on server A and the listener in server B, we have the problem (100 messages lost for 54 000 messages sent at a frequency of 5 messages per second)
if we install the MOM on server A and the listener also, we never have the problem in hte same load configuration.
What we think l is that it can be a socket lost that is badly managed by the MOM.
Could you please have a look on that and give me a status.
Thank's a lot
Regis Lebrun
----- Original Message -----
From: Julien Schreiber
To: ***@intalio.com ; ***@intalio.com
Cc: Régis Lebrun
Sent: Monday, September 29, 2003 1:52 PM
Subject: MOM replay management
Hi,
I am currently using OpenJMS MOM 0.7.5.
I have already asked some questions a few month ago that appear below.
Here is my new question : I would like to know if it is possible to tune the MOM in order to try to send again messages that have not been transmitted correctly through the MOM. It seems that with the MOM I use, if too many messages are passed in the MOM at the same time, 2 kinds of problems can occur :
- Messages are lost. No error messages or exception are caught that indicate that a problem occured. So everything seems to be done correctly from client side point of view.
- Messages take 4 seconds to be transmitted through the MOM (it normally takes a few milliseconds when everything goes well). Once again, everything seems to be done correctly from client side point of view: Messages are "sent", and there is no information that prove that queues are saturated.
I have run load tests at 15 requests per second during a few minutes. The message passed is a String. A dozen requests are lost or take a few seconds to be transmitted through the MOM (4seconds in the MOM)
Here above is the current configuration of the MOM :
************************************
<?xml version="1.0"?>
<!-- OpenJMS configuration:
. TCP connectors
. JDBM persistency
. embedded JNDI provider
. preconfigured destinations
-->
<Configuration>
<!-- Optional. This represents the default configuration -->
<ServerConfiguration host="172.28.20.131" embeddedJNDI="true" />
<!-- Connector is TCP -->
<Connectors>
<Connector scheme="rmi">
<ConnectionFactories>
<QueueConnectionFactory name="JmsQueueConnectionFactory" />
</ConnectionFactories>
</Connector>
</Connectors>
<!-- Optional. This represents the default configuration -->
<!--
<RmiConfiguration embeddedRegistry="true"
registryHost="172.28.20.131"
registryPort="1099"
clientPingInterval="15"
serverName="OpenJMSServer"
jndiName="JndiServer"
adminName="JmsAdminServer">
</RmiConfiguration>
-->
<!-- Optional. This represents the default configuration -->
<!--
<LeaseManagerConfiguration sleepTime="300" />
-->
<!-- Optional. This represents the default configuration -->
<!--
<MessageManagerConfiguration destinationCacheSize="10000" />
-->
<!-- Optional. This represents the default configuration -->
<!--
<SchedulerConfiguration maxThreads="10" />
-->
<!-- Optional. -->
<!--
<GarbageCollectionConfiguration memoryCheckInterval="60"
lowWaterThreshold="20"
garbageCollectionInterval="120"
garbageCollectionThreadPriority="5">
</GarbageCollectionConfiguration>
-->
<!-- Required -->
<!--
<DatabaseConfiguration garbageCollectionInterval="600"
garbageCollectionBlockSize="500"
garbageCollectionThreadPriority="5">
-->
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
<!-- Required -->
<AdminConfiguration
script="${openjms.home}/../../scripts/mom.sh -start"
config="${openjms.home}/../MomServer.xml" />
<!-- Optional. If not specified, no destinations will be created -->
<AdministeredDestinations>
<AdministeredQueue name="requestLocQueue" />
<AdministeredQueue name="locResultQueueA" />
<AdministeredQueue name="locResultQueueB" />
<AdministeredQueue name="isAliveQueue" />
</AdministeredDestinations>
</Configuration>
************************************
Thank in advance for your answer and tips to tune correctly the MOM
Regards,
Julien Schreiber
Cap Gemini Telecom France
----- Original Message -----
From: Jim Alateras
To: 'Julien Schreiber'
Cc: 'alexis marchand' ; 'Régis Lebrun'
Sent: Tuesday, March 25, 2003 12:12 AM
Subject: RE: Problems with version 0.7.3.1 and 0.7.4
JDBM database should not be used for load testing and is only distributed for quick out-of-the-box setup and testing. You should really choose one of RDBMS databases (i.e. mysql, hsql, oracle etc) for testing. With RDBMS we have been able to get 100's of messages per second (size of message 1KB).
You should also be using 0.7.4 or wait for the latest version 0.7.5 to be released.
If your persistent message requirements exceed 200x1KB messages/second then you may need to source a new JMS provider. However anything within the 200x1KB messages/second should be achievable with OpenJMS.
cheers
</jima>
-----Original Message-----
From: Julien Schreiber [mailto:***@cgey.com]
Sent: Monday, March 24, 2003 11:24 PM
To: ***@intalio.com
Cc: alexis marchand; Régis Lebrun
Subject: Problems with version 0.7.3.1 and 0.7.4
Hi,
We have tried to use the new version of the OpenJMS MOM : 0.7.4 on Solaris.
Performances are not as good as it was with version 0.7.3.1 : Processing Time is longer than before.
We have run a test with a frequency of 3 messages sent in the MOM per second.
Here is the configuration we used :
***********************************************************************************************************************************
<?xml version="1.0"?>
<!-- OpenJMS configuration:
. TCP connectors
. JDBM persistency
. embedded JNDI provider
. preconfigured destinations
-->
<Configuration>
<!-- Optional. This represents the default configuration -->
<ServerConfiguration host="10.67.178.28" embeddedJNDI="true" />
<!-- Connector is TCP -->
<Connectors>
<Connector scheme="rmi">
<ConnectionFactories>
<QueueConnectionFactory name="JmsQueueConnectionFactory" />
</ConnectionFactories>
</Connector>
</Connectors>
<!-- Optional. This represents the default configuration -->
<LeaseManagerConfiguration sleepTime="300" />
<!-- Optional. This represents the default configuration -->
<MessageManagerConfiguration destinationCacheSize="10" />
<!-- Optional. This represents the default configuration -->
<SchedulerConfiguration maxThreads="10" />
<!-- Optional. -->
<GarbageCollectionConfiguration memoryCheckInterval="60"
lowWaterThreshold="20"
garbageCollectionInterval="120"
garbageCollectionThreadPriority="5">
</GarbageCollectionConfiguration>
<!-- Required -->
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
<!-- Required -->
<AdminConfiguration
script="${openjms.home}/../../scripts/mom.sh -start"
config="${openjms.home}/../MomServer.xml" />
<!-- Optional. If not specified, no destinations will be created -->
<AdministeredDestinations>
<AdministeredQueue name="requestLocQueue" />
<AdministeredQueue name="locResultQueueA" />
<AdministeredQueue name="locResultQueueB" />
<AdministeredQueue name="isAliveQueue" />
</AdministeredDestinations>
</Configuration>
***********************************************************************************************************************************
We had also endurance problems with version 0.7.3.1
Here is the error messages we had during a Load Test with a frequency of 5 messages sent in the MOM per second. Error occured 1 hour after the begining of the Test :
***********************************************************************************************************************************
13:49:51.636 ERROR [Scheduler-Worker-3] - Dropping handle Handle : 0:1048427372219:1494979:ID:15591976861184663 since we cannot resolve it.
13:49:51.652 ERROR [Scheduler-Worker-3] - javax.jms.JMSException: Could not get message for handle Handle : 0:1048427372219:1494979:ID:15591976861184663
javax.jms.JMSException: Could not get message for handle Handle : 0:1048427372219:1494979:ID:15591976861184663
at org.exolab.jms.server.JmsServerSession.onMessage(Unknown Source)
at org.exolab.jms.messagemgr.QueueConsumerEndpoint.run(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runIt(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runWork(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.access$000(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:479)
15:23:51.466 ERROR [Scheduler-Worker-4] - Dropping handle Handle : 0:1048433014999:1548927:ID:7739832439311948131 since we cannot resolve it.
15:23:51.467 ERROR [Scheduler-Worker-4] - javax.jms.JMSException: Could not get message for handle Handle : 0:1048433014999:1548927:ID:7739832439311948131
javax.jms.JMSException: Could not get message for handle Handle : 0:1048433014999:1548927:ID:7739832439311948131
at org.exolab.jms.server.JmsServerSession.onMessage(Unknown Source)
at org.exolab.jms.messagemgr.QueueConsumerEndpoint.run(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runIt(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runWork(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.access$000(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:479)
02:09:59.757 ERROR [Scheduler-Worker-7] - Dropping handle Handle : 0:1048471796879:1919720:ID:6589455389744779712 since we cannot resolve it.
02:09:59.758 ERROR [Scheduler-Worker-7] - javax.jms.JMSException: Could not get message for handle Handle : 0:1048471796879:1919720:ID:6589455389744779712
javax.jms.JMSException: Could not get message for handle Handle : 0:1048471796879:1919720:ID:6589455389744779712
at org.exolab.jms.server.JmsServerSession.onMessage(Unknown Source)
at org.exolab.jms.messagemgr.QueueConsumerEndpoint.run(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runIt(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runWork(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.access$000(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:479)
***********************************************************************************************************************************
Here is the configuration we used :
***********************************************************************************************************************************
<?xml version="1.0"?>
<!-- OpenJMS configuration:
. TCP connectors
. JDBM persistency
. embedded JNDI provider
. preconfigured destinations
-->
<Configuration>
<!-- Optional. This represents the default configuration -->
<ServerConfiguration host="10.67.178.28" embeddedJNDI="true" />
<!-- Connector is TCP -->
<Connectors>
<Connector scheme="rmi">
<ConnectionFactories>
<QueueConnectionFactory name="JmsQueueConnectionFactory" />
</ConnectionFactories>
</Connector>
</Connectors>
<!-- Optional. This represents the default configuration -->
<LeaseManagerConfiguration sleepTime="300" />
<!-- Optional. This represents the default configuration -->
<MessageManagerConfiguration destinationCacheSize="10" />
<!-- Optional. This represents the default configuration -->
<SchedulerConfiguration maxThreads="10" />
<!-- Optional. -->
<GarbageCollectionConfiguration memoryCheckInterval="60"
lowWaterThreshold="20"
garbageCollectionInterval="120"
garbageCollectionThreadPriority="5">
</GarbageCollectionConfiguration>
<!-- Required -->
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
<!-- Required -->
<AdminConfiguration
script="${openjms.home}/../../scripts/mom.sh -start"
config="${openjms.home}/../MomServer.xml" />
<!-- Optional. If not specified, no destinations will be created -->
<AdministeredDestinations>
<AdministeredQueue name="requestLocQueue" />
<AdministeredQueue name="locResultQueueA" />
<AdministeredQueue name="locResultQueueB" />
<AdministeredQueue name="isAliveQueue" />
</AdministeredDestinations>
</Configuration>
***********************************************************************************************************************************
Could you tell us if the configuration we use could be appplied to the 2 versions ? Could you give us some tips to customize the MOM to increase performances and endurance ? Could you give us some information on changes between the 2 versions explaining the bad performances we saw while running the Test ?
We have 3 days to find a solution regarding both the load performances and the endurance of the MOM.
Then we will have to change the OpenJMS MOM to another one.
Regards,
___________________________
Julien Schreiber
Cap Gemini Telecom Media & Networks
+33 (0)1 49 00 47 60
___________________________
Julien Schreiber
Cap Gemini Telecom Media & Networks
+33 (0)1 49 00 47 60
___________________________
Julien Schreiber
Cap Gemini Telecom Media & Networks
+33 (0)1 49 00 47 60
I have a short question raised when I ran some tests in order to analyse the former problems (described below).
Can you confirm that the MOM where the messages are sent to corresponds to the IP address described in the MomServer.xml config file ?
Just to remind you about our problem : We are using 2 Moms running on 2 servers (hardware implementation).
What we saw during our tests is that the sender running on the first server seems to send messages on the remote Mom by using an interface that doesn't correspond to the IP address described in the MomServer.xml config file, but through an interface mentionned in the /etc/hosts file :
-> messages are sent on the address "172.26.47.14" , instead of 172.26.44.73
- bt1flocur21 is the "hostname" of the remote server
- We are using SUN V880 (Solaris 8.0)
****************************************
In the /etc/hosts file
172.26.47.14 bt1flocur21
****************************************
I have this configuration in the MomServer.xml file :
<!-- Optional. This represents the default configuration -->
<ServerConfiguration host="172.26.44.73" embeddedJNDI="true" />
****************************************
In our config file :
publiclocConfigGeneral.mom.1.host=172.26.44.73
publiclocConfigGeneral.mom.1.port=1099
****************************************
Here is the code we use to initialize our mom connections :
private Context getRmiContext() throws Exception {
/*
* connect to the JNDI server and get a reference to root context
*/
Hashtable props = new Hashtable();
// default value (to be passed in config files)
String jndiname = "JndiServer";
String mode = "rmi";
logger_.debug ("getRmiContext: host: " + host_ + ", jndiname:" + jndiname + ", mode: " + mode + ", port: " +port_);
String modeType = RmiJndiInitialContextFactory.class.getName();
/*
* put information regarding connection in the Hashtable
*/
props.put(Context.PROVIDER_URL, "rmi://" + host_ + ":" + port_ + "/" + jndiname);
props.put(Context.INITIAL_CONTEXT_FACTORY, modeType);
/*
* create context
*/
Context context = new InitialContext(props);
return context;
}
}
With host_ and port_ set with the values retrieved in our config file.
Thanks in advance for your help !
Julien
----- Original Message -----
From: Julien Schreiber
To: openjms-***@lists.sourceforge.net
Cc: 'Régis Lebrun'
Sent: Wednesday, November 19, 2003 12:06 PM
Subject: Re: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
Hi Jim,
Thanks for your answer.
default for expiration is LIVE_FOREVER (There are some additional constraints for topic message model). If the message is not delivered >within 10 seconds then the OpenJMS server will not deliver it. Try using a longer ttl or set it to -1 or 0 (you need to check the JMS >specification for the correct value) so that it doesn't expire at all.
I will test with different values : 0, -1 and a long delay (30s). I will let you know if everything goes well.I have a question relative to this solution :
- We would like to use NON_PERSISTANT messages to avoid using JDBM database. Do you think that forcing the messages not expiring at all (by configuring the TTL parameter as described above) will allow to treat messages that gathered a network problem : If the sender is running on a first server and the OpenJMS MOM is running on a remote server, if the message can't be sent because of a network problem, does the fact that the TTL is set to "0", "-1" or a longer value, make the sender keep the message in memory in order to resend ("replay") this message later ?
On the OpenJMS server side, if the listener is busy, is the message kept in memory until the listener is available to receive messages thanks to the configuration of the TTL param as "0", "-1" or longer value ?
Thanks in advance for these precisions !
Regards
Julien
----- Original Message -----
From: Jim Alateras
To: openjms-***@lists.sourceforge.net
Cc: 'Régis Lebrun'
Sent: Tuesday, November 18, 2003 8:41 PM
Subject: RE: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
Hi Jim,
thanks a lot for these precisions.
try removing the all garbageXXXXX attributes in the DatabaseConfiguration element or set garbageCollection to '0'
All parameters have been put as comment.We are using Non-persistent messages. (but the openJms.db file is created and locked.)
*****************************
here is our configuration :
<?xml version="1.0"?>
<!-- OpenJMS configuration:
. TCP connectors
. JDBM persistency
. embedded JNDI provider
. preconfigured destinations
-->
<Configuration>
<!-- Optional. This represents the default configuration -->
<ServerConfiguration host="172.28.20.131" embeddedJNDI="true" />
<!-- Connector is TCP -->
<Connectors>
<Connector scheme="rmi">
<ConnectionFactories>
<QueueConnectionFactory name="JmsQueueConnectionFactory" />
</ConnectionFactories>
</Connector>
</Connectors>
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
<!-- Required -->
<AdminConfiguration
script="${openjms.home}/../../scripts/mom.sh -start"
config="${openjms.home}/../MomServer.xml" />
<!-- Optional. If not specified, no destinations will be created -->
<AdministeredDestinations>
<AdministeredQueue name="requestLocQueue" />
<AdministeredQueue name="locResultQueueA" />
<AdministeredQueue name="locResultQueueB" />
<AdministeredQueue name="isAliveQueue" />
</AdministeredDestinations>
</Configuration>
************************************************************
here is the source code we use to send messages :
String connectionFactoryName = "JmsQueueConnectionFactory" ;
QueueConnectionFactory connectionFactory = (QueueConnectionFactory)context.lookup(connectionFactoryName);
QueueConnection connection_ = connectionFactory.createQueueConnection();
connection_.setExceptionListener(new ExceptionListener());
connection_.start();
QueueSession session_ = connection_.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
//method called to send message in the MOM
public void send (Serializable object, String queueName) throws javax.jms.J
MSException {
Queue queue = (Queue)queueMap_.get (queueName);
QueueSender sender = session_.createSender(queue);
ObjectMessage message = session_.createObjectMessage();
message.setJMSDeliveryMode(DeliveryMode.NON_PERSISTENT);
message.setObject(object);
sender.send(message, DeliveryMode.NON_PERSISTENT, 1, 10000);
}
Here are my questions :
- do you think the parameters passed to the send method are correct ? TimeTolive=10000 and priority=1
there is no problem with the parameters. TTL is 10 seconds and priority is 1.
- Do you think that parameters of the ObjectMessage could be set uncorrectly ; for instance parameters such as JMSDestination, JMSExpiration, JMSTimeStamp, JMSMessageId. Normally these parameters are set automatically when the message is sent. But do you think that in the scope of our problem (messages lost when using a OpenJMS server running on a remote server) one of these parameters could be set badly. Is this possible ?
it may be a problem although I am relatively confident that this is not where your problem lies.
For instance what is the default value of the JMSExpiration parameter ? If a network problem exists that force the message to spend some time before reaching the remote OpenJMS Server (running on a remote server), is the message lost ?
default for expiration is LIVE_FOREVER (There are some additional constraints for topic message model). If the message is not delivered within 10 seconds then the OpenJMS server will not deliver it. Try using a longer ttl or set it to -1 or 0 (you need to check the JMS specification for the correct value) so that it doesn't expire at all.
Thanks a lot in advance for your help.
At the beginning, we thought that the JDBM database was the source of our problem. But perhaps this is our customization of the openJMS MOM that is not able to manage network problems that could occur between the 2 servers where the 2 MOM are running.
the problem is most likely related to the TTL value passed to sender.send
cheers
</jima>
Regards,
Julien
----- Original Message -----
From: Jim Alateras
To: openjms-***@lists.sourceforge.net
Cc: 'Régis Lebrun'
Sent: Monday, November 17, 2003 7:27 PM
Subject: RE: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
Hi Tim,
Since I have had no news from you since last wednesday, I contact you again regarding the problem we have with OpenJMS MOM 0.7.5.
Tim will be away for the until Wednesday.
Below are my previous questions. Once again, we are looking for a mean to customize the JDBM database, because we can't use RBDMS database in the scope of our project
You should be aware that we will stop supporting JDBM, if we haven't already so you need to look for an alternative (i.e. hsql)
My questions are :
- does our configuration explain our problems regarding messages lost when using 2 MOM on 2 servers (physical hardware implementation) ? (this problem is described below in my previous mails)
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
<!--
<DatabaseConfiguration garbageCollectionInterval="600"
garbageCollectionBlockSize="500"
garbageCollectionThreadPriority="5">
-->
- Is there a way to indicate that "No Garbage Collection should be used" ? Perhaps when we are running 2 Moms on 2 servers, some messages are deleted on one server while the other server have not received the messages yet...
try removing the all garbageXXXXX attributes in the DatabaseConfiguration element or set garbageCollection to '0'
- Do you think it is possible that the "remote" listener couldn't "retrieve" messages in the database ? Is it a problem of synchronism between 2 applications reading the same file (containing data) ?
can you elaborate?
- What happens when for One MOM running on a server (physical hardware implementation), the application that sends messages in the MOM is running on one Server and the listener is running on the other server (physical hardware implementation) ? Is the db file readable by the 2 applications ?
the db file is locked when the server is running so you can't run 2 OpenJMS server's pointing to the same openjms.db file (if that's what you're asking)
- what is the openJms.db file exactly used for ?
for persistent messages
Thanks in advance for your answers,
We have to give an answers by the end of the week
Regards,
Julien
----- Original Message -----
From: Julien Schreiber
To: openjms-***@lists.sourceforge.net
Cc: Régis Lebrun
Sent: Wednesday, November 12, 2003 2:01 PM
Subject: Re: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
Hi Tim,
thanks a lot for your answer and your precisions. ( Infact, we couldn't log in and read your first answer...)
The problem is that we can't use RBDMS database in the scope of our project. So we will have to customize the JDBM database.
- In our configuration file, there is only one parameter linked to the database configuration :
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
The other parameters are put as comments.
Do you think this configuration is enough ?
- Do you think that the lost of messages described in our previous messages :
" The problem is systematically reproduced when we use a listener on another server (physical hardware implementation) than the MOM
It is not due to a huge traffic.
We use server A and server B.
If we install the MOM on server A and the listener in server B, we have the problem (100 messages lost for 54 000 messages sent at a frequency of 5 messages per second)
if we install the MOM on server A and the listener also, we never have the problem in hte same load configuration.
What we think l is that it can be a socket lost that is badly managed by the MOM."
....can be explained by the use of the JDBM database (or by a bad configuration of the database in the config file ?)
Could you explain me what kind of messages are stored in the JDBM database ?
Do you think it is possible that the "remote" listener couldn't "retrieve" messages in the database ? Is it a problem of synchronism between 2 applications reading the same file (containing data) ?
Thanks in advance for your help !
Regards,
Julien
----- Original Message -----
From: Tim Anderson
To: openjms-***@lists.sourceforge.net
Sent: Wednesday, November 05, 2003 5:54 AM
Subject: RE: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
I responded to this a while ago: http://sourceforge.net/mailarchive/message.php?msg_id=6246957
The only thing I can add is that I don't think database garbage collection was working correctly in 0.7.5.
This is no longer needed, and has been removed in 0.7.6.
If you have it enabled, turn it off, by removing the garbageCollection* properties on
the <DatabaseConfiguration/> element in openjms.xml
-Tim
-----Original Message-----
From: openjms-developer-***@lists.sourceforge.net [mailto:openjms-developer-***@lists.sourceforge.net]On Behalf Of Julien Schreiber
Sent: Wednesday, 5 November 2003 1:48 AM
To: openjms-***@lists.sourceforge.net
Cc: Régis Lebrun
Subject: [openjms-developer] MOM replay management : OpenJMS MOM 0.7.5.
Hi,
Sorry if you have already received this mail. I just received a confirmation saying that I have joined successfully the Mailing list so I try to send it again...
Régis and I try to contact you for a problem occured on our OpenJMS MOM 0.7.5.
Our problem is described below...
Below is also an answer Jima gave us a few monthes ago concerning performances of the MOM. He answered about JDBM database. Do you think our problem could be linked to this ? Do you think the configuration of the MOM is correct ?
Thanks in advance to give us some help or any answer prouving that this email reached someone successfully !!
Kind regards,
Julien Schreiber
Cap Gemini Telecom France
----- Original Message -----
From: Régis LEBRUN
To: openjms-***@lists.sourceforge.net
Cc: Julien Schreiber
Sent: Thursday, October 09, 2003 5:06 PM
Subject: Fw: MOM replay management : OpenJMS MOM 0.7.5.
I received a mail error sending my email to my previews contacts on OpenJMS. I don't know why.
please find here after a brief description of our problem.
I hope you will be able to help us
Kind Regards
Régis Lebrun
----- Original Message -----
From: Régis LEBRUN
To: ***@intalio.com ; ***@intalio.com
Cc: Julien Schreiber
Sent: Thursday, October 09, 2003 5:23 PM
Subject: MOM replay management : OpenJMS MOM 0.7.5.
Hi,
Julien, a guy working in my team sent you an email last week. As we didn't receive any news from you and as the problem is quite important (lost of messages), I wanted to bring you some precisions. Please, we need a quick answer.
The problem is systematically reproduced when we use a listener on another server (physical hardware implementation) than the MOM
It is not due to a huge traffic.
We use server A and server B.
If we install the MOM on server A and the listener in server B, we have the problem (100 messages lost for 54 000 messages sent at a frequency of 5 messages per second)
if we install the MOM on server A and the listener also, we never have the problem in hte same load configuration.
What we think l is that it can be a socket lost that is badly managed by the MOM.
Could you please have a look on that and give me a status.
Thank's a lot
Regis Lebrun
----- Original Message -----
From: Julien Schreiber
To: ***@intalio.com ; ***@intalio.com
Cc: Régis Lebrun
Sent: Monday, September 29, 2003 1:52 PM
Subject: MOM replay management
Hi,
I am currently using OpenJMS MOM 0.7.5.
I have already asked some questions a few month ago that appear below.
Here is my new question : I would like to know if it is possible to tune the MOM in order to try to send again messages that have not been transmitted correctly through the MOM. It seems that with the MOM I use, if too many messages are passed in the MOM at the same time, 2 kinds of problems can occur :
- Messages are lost. No error messages or exception are caught that indicate that a problem occured. So everything seems to be done correctly from client side point of view.
- Messages take 4 seconds to be transmitted through the MOM (it normally takes a few milliseconds when everything goes well). Once again, everything seems to be done correctly from client side point of view: Messages are "sent", and there is no information that prove that queues are saturated.
I have run load tests at 15 requests per second during a few minutes. The message passed is a String. A dozen requests are lost or take a few seconds to be transmitted through the MOM (4seconds in the MOM)
Here above is the current configuration of the MOM :
************************************
<?xml version="1.0"?>
<!-- OpenJMS configuration:
. TCP connectors
. JDBM persistency
. embedded JNDI provider
. preconfigured destinations
-->
<Configuration>
<!-- Optional. This represents the default configuration -->
<ServerConfiguration host="172.28.20.131" embeddedJNDI="true" />
<!-- Connector is TCP -->
<Connectors>
<Connector scheme="rmi">
<ConnectionFactories>
<QueueConnectionFactory name="JmsQueueConnectionFactory" />
</ConnectionFactories>
</Connector>
</Connectors>
<!-- Optional. This represents the default configuration -->
<!--
<RmiConfiguration embeddedRegistry="true"
registryHost="172.28.20.131"
registryPort="1099"
clientPingInterval="15"
serverName="OpenJMSServer"
jndiName="JndiServer"
adminName="JmsAdminServer">
</RmiConfiguration>
-->
<!-- Optional. This represents the default configuration -->
<!--
<LeaseManagerConfiguration sleepTime="300" />
-->
<!-- Optional. This represents the default configuration -->
<!--
<MessageManagerConfiguration destinationCacheSize="10000" />
-->
<!-- Optional. This represents the default configuration -->
<!--
<SchedulerConfiguration maxThreads="10" />
-->
<!-- Optional. -->
<!--
<GarbageCollectionConfiguration memoryCheckInterval="60"
lowWaterThreshold="20"
garbageCollectionInterval="120"
garbageCollectionThreadPriority="5">
</GarbageCollectionConfiguration>
-->
<!-- Required -->
<!--
<DatabaseConfiguration garbageCollectionInterval="600"
garbageCollectionBlockSize="500"
garbageCollectionThreadPriority="5">
-->
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
<!-- Required -->
<AdminConfiguration
script="${openjms.home}/../../scripts/mom.sh -start"
config="${openjms.home}/../MomServer.xml" />
<!-- Optional. If not specified, no destinations will be created -->
<AdministeredDestinations>
<AdministeredQueue name="requestLocQueue" />
<AdministeredQueue name="locResultQueueA" />
<AdministeredQueue name="locResultQueueB" />
<AdministeredQueue name="isAliveQueue" />
</AdministeredDestinations>
</Configuration>
************************************
Thank in advance for your answer and tips to tune correctly the MOM
Regards,
Julien Schreiber
Cap Gemini Telecom France
----- Original Message -----
From: Jim Alateras
To: 'Julien Schreiber'
Cc: 'alexis marchand' ; 'Régis Lebrun'
Sent: Tuesday, March 25, 2003 12:12 AM
Subject: RE: Problems with version 0.7.3.1 and 0.7.4
JDBM database should not be used for load testing and is only distributed for quick out-of-the-box setup and testing. You should really choose one of RDBMS databases (i.e. mysql, hsql, oracle etc) for testing. With RDBMS we have been able to get 100's of messages per second (size of message 1KB).
You should also be using 0.7.4 or wait for the latest version 0.7.5 to be released.
If your persistent message requirements exceed 200x1KB messages/second then you may need to source a new JMS provider. However anything within the 200x1KB messages/second should be achievable with OpenJMS.
cheers
</jima>
-----Original Message-----
From: Julien Schreiber [mailto:***@cgey.com]
Sent: Monday, March 24, 2003 11:24 PM
To: ***@intalio.com
Cc: alexis marchand; Régis Lebrun
Subject: Problems with version 0.7.3.1 and 0.7.4
Hi,
We have tried to use the new version of the OpenJMS MOM : 0.7.4 on Solaris.
Performances are not as good as it was with version 0.7.3.1 : Processing Time is longer than before.
We have run a test with a frequency of 3 messages sent in the MOM per second.
Here is the configuration we used :
***********************************************************************************************************************************
<?xml version="1.0"?>
<!-- OpenJMS configuration:
. TCP connectors
. JDBM persistency
. embedded JNDI provider
. preconfigured destinations
-->
<Configuration>
<!-- Optional. This represents the default configuration -->
<ServerConfiguration host="10.67.178.28" embeddedJNDI="true" />
<!-- Connector is TCP -->
<Connectors>
<Connector scheme="rmi">
<ConnectionFactories>
<QueueConnectionFactory name="JmsQueueConnectionFactory" />
</ConnectionFactories>
</Connector>
</Connectors>
<!-- Optional. This represents the default configuration -->
<LeaseManagerConfiguration sleepTime="300" />
<!-- Optional. This represents the default configuration -->
<MessageManagerConfiguration destinationCacheSize="10" />
<!-- Optional. This represents the default configuration -->
<SchedulerConfiguration maxThreads="10" />
<!-- Optional. -->
<GarbageCollectionConfiguration memoryCheckInterval="60"
lowWaterThreshold="20"
garbageCollectionInterval="120"
garbageCollectionThreadPriority="5">
</GarbageCollectionConfiguration>
<!-- Required -->
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
<!-- Required -->
<AdminConfiguration
script="${openjms.home}/../../scripts/mom.sh -start"
config="${openjms.home}/../MomServer.xml" />
<!-- Optional. If not specified, no destinations will be created -->
<AdministeredDestinations>
<AdministeredQueue name="requestLocQueue" />
<AdministeredQueue name="locResultQueueA" />
<AdministeredQueue name="locResultQueueB" />
<AdministeredQueue name="isAliveQueue" />
</AdministeredDestinations>
</Configuration>
***********************************************************************************************************************************
We had also endurance problems with version 0.7.3.1
Here is the error messages we had during a Load Test with a frequency of 5 messages sent in the MOM per second. Error occured 1 hour after the begining of the Test :
***********************************************************************************************************************************
13:49:51.636 ERROR [Scheduler-Worker-3] - Dropping handle Handle : 0:1048427372219:1494979:ID:15591976861184663 since we cannot resolve it.
13:49:51.652 ERROR [Scheduler-Worker-3] - javax.jms.JMSException: Could not get message for handle Handle : 0:1048427372219:1494979:ID:15591976861184663
javax.jms.JMSException: Could not get message for handle Handle : 0:1048427372219:1494979:ID:15591976861184663
at org.exolab.jms.server.JmsServerSession.onMessage(Unknown Source)
at org.exolab.jms.messagemgr.QueueConsumerEndpoint.run(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runIt(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runWork(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.access$000(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:479)
15:23:51.466 ERROR [Scheduler-Worker-4] - Dropping handle Handle : 0:1048433014999:1548927:ID:7739832439311948131 since we cannot resolve it.
15:23:51.467 ERROR [Scheduler-Worker-4] - javax.jms.JMSException: Could not get message for handle Handle : 0:1048433014999:1548927:ID:7739832439311948131
javax.jms.JMSException: Could not get message for handle Handle : 0:1048433014999:1548927:ID:7739832439311948131
at org.exolab.jms.server.JmsServerSession.onMessage(Unknown Source)
at org.exolab.jms.messagemgr.QueueConsumerEndpoint.run(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runIt(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runWork(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.access$000(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:479)
02:09:59.757 ERROR [Scheduler-Worker-7] - Dropping handle Handle : 0:1048471796879:1919720:ID:6589455389744779712 since we cannot resolve it.
02:09:59.758 ERROR [Scheduler-Worker-7] - javax.jms.JMSException: Could not get message for handle Handle : 0:1048471796879:1919720:ID:6589455389744779712
javax.jms.JMSException: Could not get message for handle Handle : 0:1048471796879:1919720:ID:6589455389744779712
at org.exolab.jms.server.JmsServerSession.onMessage(Unknown Source)
at org.exolab.jms.messagemgr.QueueConsumerEndpoint.run(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runIt(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.runWork(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker.access$000(Unknown Source)
at org.exolab.core.threadPool.ThreadPoolWorker$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:479)
***********************************************************************************************************************************
Here is the configuration we used :
***********************************************************************************************************************************
<?xml version="1.0"?>
<!-- OpenJMS configuration:
. TCP connectors
. JDBM persistency
. embedded JNDI provider
. preconfigured destinations
-->
<Configuration>
<!-- Optional. This represents the default configuration -->
<ServerConfiguration host="10.67.178.28" embeddedJNDI="true" />
<!-- Connector is TCP -->
<Connectors>
<Connector scheme="rmi">
<ConnectionFactories>
<QueueConnectionFactory name="JmsQueueConnectionFactory" />
</ConnectionFactories>
</Connector>
</Connectors>
<!-- Optional. This represents the default configuration -->
<LeaseManagerConfiguration sleepTime="300" />
<!-- Optional. This represents the default configuration -->
<MessageManagerConfiguration destinationCacheSize="10" />
<!-- Optional. This represents the default configuration -->
<SchedulerConfiguration maxThreads="10" />
<!-- Optional. -->
<GarbageCollectionConfiguration memoryCheckInterval="60"
lowWaterThreshold="20"
garbageCollectionInterval="120"
garbageCollectionThreadPriority="5">
</GarbageCollectionConfiguration>
<!-- Required -->
<DatabaseConfiguration>
<JdbmDatabaseConfiguration name="openjms.db" />
</DatabaseConfiguration>
<!-- Required -->
<AdminConfiguration
script="${openjms.home}/../../scripts/mom.sh -start"
config="${openjms.home}/../MomServer.xml" />
<!-- Optional. If not specified, no destinations will be created -->
<AdministeredDestinations>
<AdministeredQueue name="requestLocQueue" />
<AdministeredQueue name="locResultQueueA" />
<AdministeredQueue name="locResultQueueB" />
<AdministeredQueue name="isAliveQueue" />
</AdministeredDestinations>
</Configuration>
***********************************************************************************************************************************
Could you tell us if the configuration we use could be appplied to the 2 versions ? Could you give us some tips to customize the MOM to increase performances and endurance ? Could you give us some information on changes between the 2 versions explaining the bad performances we saw while running the Test ?
We have 3 days to find a solution regarding both the load performances and the endurance of the MOM.
Then we will have to change the OpenJMS MOM to another one.
Regards,
___________________________
Julien Schreiber
Cap Gemini Telecom Media & Networks
+33 (0)1 49 00 47 60
___________________________
Julien Schreiber
Cap Gemini Telecom Media & Networks
+33 (0)1 49 00 47 60
___________________________
Julien Schreiber
Cap Gemini Telecom Media & Networks
+33 (0)1 49 00 47 60