Menu
▾
▴
Re: [openjms-user] JMS connection issues
|
From: Govinda R. D. <Gov...@in...> - 2007-04-30 05:57:16
|
Dear Tim,
=20
Many thanks for your explanation. I appreciate this.
=20
Thanks & Regards
Govind
=20
________________________________
From: ope...@li...
[mailto:ope...@li...] On Behalf Of Tim
Anderson
Sent: Monday, April 30, 2007 5:20 AM
To: ope...@li...
Subject: Re: [openjms-user] JMS connection issues
=20
See inline:
Govinda Rao Deyyam wrote:=20
Hi Tim,
=20
Thanks for your reply. But still I am not clear with your answers.
>From your first statement, you mean a new connection object will be
created but will be given to the same address location ...am I correct?
How is it happening...how come the same address will be given for the
next object? You mean when we close the Sender program the connection
object or address is not getting freed from the memory....is it? In this
case if I run a Receiver program followed by Sender program then the
same address should be given for the connection object created in
Receiver program, but not happening. Who is allocating address and
creating connection objects in this case?
=20
Can you explain the below question?
1. Run a Sender program and the address is abcd@abcd
2. run a Receiver program and the address is wxyz@xyz
3. run the sender program again but got the same address abcd@abcd
4. run the sender program again but got the same address wxyz@xyz
How am I getting the same address for a particular program ...how is
this mapping happening?
The @abcd and @xyz are derived from the hashCode() of the connection
object. The implementation of hashCode() used
is that provided by java.lang.Object.hashCode(). From the javadoc:
....
* As much as is reasonably practical, the hashCode method defined by
* class <tt>Object</tt> does return distinct integers for distinct=20
* objects. (This is typically implemented by converting the
internal=20
* address of the object into an integer
...
When you print the connection, the
Object.toString() method is being called, which simply does the
following:
return getClass().getName() + "@" + Integer.toHexString(hashCode());
=20
your second statement "If you create an instance of another object prior
to the creation of the connection you should see the connection address
change "is not clear to me.
In my examples I am running the sender program second time means I am
creating instance of the Sender freshly who creates a connection object.
In this case there should be new address.
It is a new address. You are running in a different instance of the JVM
which just happens to allocate the object to the same internal address
in the new JVM.
My point was that if you changed the example programs to create another
object (anything, e,g new Long(0)) just prior to establishing the
connection,
the internal address of the connection object would be allocated to a
different address.
=20
My second issue: The firewall is closing the connection after some
inactive time (got confirmed). So we have coded that when ever we get a
IllegalStateException or JMSException then creating new connection.
=20
Thanks
Govind
=20
________________________________
From: ope...@li...
[mailto:ope...@li...] On Behalf Of Tim
Anderson
Sent: Saturday, April 28, 2007 12:22 PM
To: ope...@li...
Subject: Re: [openjms-user] JMS connection issues
=20
See inline:
Govinda Rao Deyyam wrote:=20
Dear Users,
=20
I have few queries on JMS connection mechanism.
=20
I have tried running the example programs (SimpleReceiver, SimpleSender)
and found a strange thing.=20
I am printing the connection object after getting the connection from
the factory object, code given below
=20
QueueConnectionFactory factory =3D (QueueConnectionFactory)
context.lookup(factoryName);
QueueConnection connection =3D
factory.createQueueConnection();
connection.start();
System.out.println("connection is : "+connection);
=20
But I am getting the same connection object every time when I run this
program, given the results below. When the program is closed the objects
instantiated by that program should also be freed and when we run the
program next time new objects should be created but its not happening in
this case.
Example, same object is getting returned for the SenderProgram every
time we run, same object getting returned for Receiver program every
time we run. But the object is different for sender and receiver
programs (have highlighted below).
=20
Even if I close the connection at the end of the program the same object
is getting returned when I run the program second, third..etc times.
=20
Coud anyone please explain this funda?
It just means that the connection object is being allocated to the same
address each time the program is run.
If you create an instance of another object prior to the creation of the
connection you should see the connection address change.
=20
=20
Sender program:
E:\openjms-0.7.5\src\examples\openjms\examples\client\console>java -cp
%classpath% openjms.examples.client.console.SimpleSender -queue request2
-mode tcp -jndiport 3055 -jndihost localhost -count 1
connection is : org.exolab.jms.client.JmsQueueConnection@6b7920
Publishing org.exolab.jms.message.BytesMessageImpl@1cdeff
=20
E:\openjms-0.7.5\src\examples\openjms\examples\client\console>java -cp
%classpath% openjms.examples.client.console.SimpleSender -queue request2
-mode tcp -jndiport 3055 -jndihost localhost -count 1
connection is : org.exolab.jms.client.JmsQueueConnection@6b7920
Publishing org.exolab.jms.message.BytesMessageImpl@1cdeff
=20
E:\openjms-0.7.5\src\examples\openjms\examples\client\console>java -cp
%classpath% openjms.examples.client.console.SimpleSender -queue request2
-mode tcp -jndiport 3055 -jndihost localhost -count 1
connection is : org.exolab.jms.client.JmsQueueConnection@6b7920
Publishing org.exolab.jms.message.BytesMessageImpl@1cdeff
=20
=20
Receiver Program:
E:\openjms-0.7.5\src\examples\openjms\examples\client\console>java -cp
%classpath% openjms.examples.client.console.SimpleReceiver -queue
request2=20
-mode tcp -jndiport 3055 -jndihost localhost -count 1
connection is : org.exolab.jms.client.JmsQueueConnection@63b895
[1 of 1] ObjectMessage JMSDeliveryMode=3DPERSISTENT, Priority=3D4,
JMSMessageID=3DID:4734191357462726621
=20
E:\openjms-0.7.5\src\examples\openjms\examples\client\console>java -cp
%classpath% openjms.examples.client.console.SimpleReceiver -queue
request2=20
-mode tcp -jndiport 3055 -jndihost localhost -count 1
connection is : org.exolab.jms.client.JmsQueueConnection@63b895
[1 of 1] ObjectMessage JMSDeliveryMode=3DPERSISTENT, Priority=3D4,
JMSMessageID=3DID:2767882215716415820
=20
E:\openjms-0.7.5\src\examples\openjms\examples\client\console>java -cp
%classpath% openjms.examples.client.console.SimpleReceiver -queue
request2=20
-mode tcp -jndiport 3055 -jndihost localhost -count 1
connection is : org.exolab.jms.client.JmsQueueConnection@63b895
[1 of 1] ObjectMessage JMSDeliveryMode=3DPERSISTENT, Priority=3D4,
JMSMessageID=3DID:2767882215716415819
=20
=20
=20
Q2. Is there any possibility that JMS Server closes the connection after
some inactive time (might be configurable)?
We are currently facing one problem where the connection is
getting closed after some inactive time; we are suspecting that firewall
is closing this connection, due to this we are getting
illegalStateException when we call any operation on the connection
object.
=20
Whats the stack trace?
I appreciate the earliest response.
=20
Thanks & Regards
Govinda Rao
=20
-Tim
=20
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=
solely for the use of the addressee(s). If you are not the intended=
recipient, please notify the sender by e-mail and delete the original=
message. Further, you are not to copy, disclose, or distribute this e-mail=
or its contents to any other person and any such actions are unlawful.=
This e-mail may contain viruses. Infosys has taken every reasonable=
precaution to minimize this risk, but is not liable for any damage you may=
sustain as a result of any virus in this e-mail. You should carry out your=
own virus checks before opening the e-mail or attachment. Infosys reserves=
the right to monitor and review the content of all messages sent to or=
from this e-mail address. Messages sent to or from this e-mail address may=
be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS*** |