| Author |
Message
|
| kayoumt |
 Posted: Mon Aug 31, 2009 9:19 pm Post subject: |
 |
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
fjb_saper,
I did some debugging and some research on JMS. I found out two interesting conclusions :
1) The feature I implemented does not need to use Multi-Threading ; XMS sessions could do the work.
2) It seems the performance problem my application is having is mainly experienced when I put or get a message on a persistent or temporary queue.
------------- How the feature could be implemented without multi-thread ? -------------
- Only one connection is created by my application to make possible sharing temporary queues between two sessions (created from the same connection).
Session1
- open a persistent queue
- Write message (request) on a persistent queue
- Waits for response - receive (delay) - on a temporary reply queue
Session2
- creates temporary reply queue
- listens for responses on a MessageListener
- writes messages (received by Listener) in temporary reply queue
Note : The temporary reply queue is shared by the two sessions and could be created by Session1 or Session2.
--------------------------------------------------------------------------------------
Seems very simple ; but, so far, is too slow. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Sep 01, 2009 6:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Obviously it looks like session1 and session2 share the same connection.
They should not!.
While session1 is waiting for a message to be received you cannot send in the session2 because the connection is busy waiting for the message in session1.
Sessions are being used as transactional boundaries.
Each instance of a pattern (request receive) should use its own connection and session. At the same time you might want to look into connection pooling.
While it takes little time to establish a session, establishing a connection can be quite costly...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kayoumt |
| Posted: Tue Sep 01, 2009 7:24 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
1) Connection and Session performance is not a big issue for my application. I create them at the beginning of the application and close them at the end.
2) I have read somewhere that temporary queues cannot be shared by two sessions created from two different connections.
I'll rewrite my solution with lists at the place of temporary queues. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 01, 2009 1:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kayoumt wrote: |
1) Connection and Session performance is not a big issue for my application. I create them at the beginning of the application and close them at the end.
2) I have read somewhere that temporary queues cannot be shared by two sessions created from two different connections.
I'll rewrite my solution with lists at the place of temporary queues. |
I'm thinking you're chasing a red herring there.
Are you sure that the slowness is not a function of your firewall?
After all your connections are TCP/IP... If anything in that infrastructure creates slowness MQ is going to be victimized by it.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kayoumt |
| Posted: Tue Sep 01, 2009 6:26 pm Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
[quote]I'm thinking you're chasing a red herring there.
[/quote]
I'm seriously seeking to solve my XMS slowness problem. You'll be kind to help me if you have some hints.
Back to the problem :
I created and started Connection1/Session1, Connection2/Session2
- Session1 sends request by writing in the persistent queue.
- Session2 listens for reply messages
If the listener of Session2 is not started
Session1 queue Send IS TOO FAST, Speed=X.
Else
Even if the listen does nothing
Session1 queue Send IS TOO SLOW, Speed = X/50.
End |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Tue Sep 01, 2009 7:55 pm Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
Yes, Temporary queues created on one connection can not be used in another connection.
Putting a persistant message will be slow compared to putting a non-persistant message because the persistent message needs to be written to disk.
Please refer to XMS Documentation, there is Request/Response type of messaging which appears to suit your needs. In request/response messaging you are not required to create temporary queue, XMS will manage that for you. You just created request message and put it on a required queue and then wait for response message. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 01, 2009 7:59 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Sorry but your problem is very unclear:
You create connection1 (for session1) and connection2 (for session2)
You called connection start on each of the connections.
Both connections are in started status.
So you have a requester (Session1)
Session1 creates a request message.
Session1 creates a temporary queue and sets it as ReplyTo destination on the message.
It sends a message to a server destination = server's input queue.
Session1 commits the message to the server.
Session1 extracts the messageID from the message
Session1 creates the selector for the correlationId using the above messageID
Session1 creates the receiver with the selector.
Session1 does a receive(long) on the JMSReplyTo destination.
Session1 receives the message.
Session1 commits.
Parallel or in another JVM/CLR assembly
Session2 does a receive(long) in a loop or uses the MessageListener (onMessage method)
Session2 receives the request message.
Session2 processes the request message.
Session2 creates the reply message.
Session2 checks that the correlationId of the request message is MQCI_NONE.
Session2 sets the correlationId of the reply message.
Session2 retrieves the replyto Destination from the request message
Session2 uses the anonymous sender to send the reply message to the replyto destination
Session 2 commits.
Now the time between queues should really be negligible. The wait time is really driven by the time session 2 takes to process the message and by the size of the messages. (put and get times increase with huge messages)
Of course if need be, you can log all those operations/steps and find out exactly where the time is being spent.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kayoumt |
| Posted: Wed Sep 02, 2009 7:45 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
fjb_saper
| Quote: |
Session2 uses the anonymous sender to send the reply message to the replyto destination
|
shashikanth_in
| Quote: |
Yes, Temporary queues created on one connection can not be used in another connection.
|
|
|
| Back to top |
|
|
| sonyman |
| Posted: Wed Sep 02, 2009 8:27 am Post subject: |
|
|
Newbie
Joined: 02 Sep 2009
Posts: 3
|
Hi,
i currently experience similar problems.
I habe a Windows Form (C#) receiving and displaying messages using the asynchronous message consumer. This works really fine and fast!
Another thing i do in this c# application is to put messages to a queue, and this IS really slow. This method takes about 10 seconds
| Code: |
| producer.Send(msg); |
the first time invoked, and afterwards about 3-4 seconds...
But this is only when working in client mode. Bindings mode is as fast as i would have expected it.
(for putting or getting messages i have seperate connections, sessions, destinations, etc.).
@kayoumt: What mode are you using? Binding or Client?
@all: any ideas? There is no firewall and using "native" mq speed is fine... |
|
| Back to top |
|
|
| kayoumt |
| Posted: Wed Sep 02, 2009 2:47 pm Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
I'm using CLIENT connection mode. The XMS documentation says that it is the default connection mode for .NET. I have the same delays you had (between 4s and 10s).
I'm not sure, but I think if you set your connection with BINDINGS, your MQ client will not be able to communicate (network) with a remote MQ server ? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 02, 2009 4:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Open a PMR with IBM and ask them why you are experiencing such a delay.
This is definitely not normal. You'll probably have to supply user traces...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kayoumt |
| Posted: Wed Sep 02, 2009 7:27 pm Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
| Thank you so much, Sonyman, for that workaround. With the BINDINGS mode it works TOO FAST ; maybe faster than before migration to XMS. |
|
| Back to top |
|
|
| sonyman |
| Posted: Thu Sep 03, 2009 12:57 am Post subject: |
|
|
Newbie
Joined: 02 Sep 2009
Posts: 3
|
you're welcome kaymount 
I think having your application and queue manager on the same machine but using client mode is never a good idea, unless you will have seperate machines later and you only want to test / develope.
I'm afraid I'll have to open a PMR, but first I'll hava a look on the trace on my own  |
|
| Back to top |
|
|
| sonyman |
| Posted: Fri Sep 04, 2009 1:41 am Post subject: |
|
|
Newbie
Joined: 02 Sep 2009
Posts: 3
|
Now I have got something for you to make confusion complete.
I wanted to have a look at the trace, and so I created an application configuration file. When i specified the default values I found in "Message Service Clients for C/C++ and .NET" manual, the applikation behaved in the old manner.
But the output of the trace was too much, i altered the file. Then my application ran as fast as in BINDINGS mode ...
try this: Create an application configuration file in the same folder as your executables (something like XmsWindowsApplication.exe.config) containing this "dummy" Trace informations:
| Code: |
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<configSections>
<sectionGroup name="IBM.XMS">
<section name="Trace" type="System.Configuration.SingleTagSectionHandler" />
</sectionGroup>
</configSections>
</configuration> |
Normally there would be a <IBM.XMS> which i just removed to speed things up 
edit: sorry, it does not work anymor, I don't know why  Just after posting the "solution", thank you, Murphy |
|
| Back to top |
|
|
| kayoumt |
| Posted: Fri Sep 04, 2009 10:11 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
Sorry Sonyman,
Your last post really "confused" me !
Did you finally make your C# application run faster with CLIENT connection mode ? |
|
| Back to top |
|
|
|
|
