Re: Queue hogging by a single consumer.

2006-08-18 Thread ahamad



James.Strachan wrote:
 
On 8/17/06, Naveen Rawat [EMAIL PROTECTED] wrote:
 Hi James,

 Thanks for your response.


  Are you trying to implement request-response with A, B, C making
  requests on Z and getting the response? Or can A, B, C process any
  message from Z?


 Exactly the first case.
 A, B, C making requests on Z and getting the response from Z



  I'm not sure if your issue is that say A doesn't see the responses for
  its request (if thats the case use either 3 queues, use temporary
  queues for the responses or use a selector and a correlationID on the
  request  response) - or is it that you have a small number of
  responses from Z and they are being hogged by one consumer - in which
  case setting a small prefetch and a round robin dispatch policy will
  fix this.


 Its that,  A doesn't see the responses for its requests made.

 I would really appreciate if I can get some help stuff on -
 1) Creating, destroying and maintaining data in temporary
 queues.
 2) Setting selector and correlationID in messages.
 
Details here
 
http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html
 
for 1) just call session.createTemporaryQueue() and set that queue on
the Message.setJMSReplyTo() property so that services can reply to
your temporary queue. They are deleted when A terminates so there's no
issue with maintaining data.
 
  Message.setJMSReplyTo( destination) API wants to set the destination so
 please tell me How I can set the destination for that and How Sender gets
 this responce without set the MessageListener  at the sender site. Please
 help me ...
 
 
for 2) just add a JMSCorrelationID() to the request messages you send
as requests. You can then use a selector such as JMSCorrelationID =
'abc' on the consumer for responses so that responses are filtered to
only return A's results etc
 
The contract of Z whichever option you go with is the to copy the
JMSCorrelationID property from the request to the response message and
send the response message to the request.getJMSReployTo() destination
 
-- 
 
James
---
http://radio.weblogs.com/0112098/
 


Thanks 
Arashad Ahmad
-- 
View this message in context: 
http://www.nabble.com/Queue-hogging-by-a-single-consumer.-tf2119797.html#a5866866
Sent from the ActiveMQ - Dev forum at Nabble.com.



Re: Queue hogging by a single consumer.

2006-08-18 Thread Naveen Rawat



Hi James, 



Arshad started it here, so I think follow it here only. 

Thanks for those pseudo directives. 

I followed those to find out that for once server receives the requests, it 
does not sends response back to the client.
After receiving the first request, the server goes napping. 

I think you missed session::createProducer at server side, without which 
it is giving SIGSEGV fault. Correct me? 



I have done it like this - 

	[..Client side... 


pIDestinationTqueue = session-createTemporaryQueue() ;
consumer = session-createConsumer(Tqueue, JMSCorrelationID = 
'butter') ;
	consumer-setMessageListener( smartify(this) ) ;	 


//sending request
reqmessage = session-createBytesMessage() ;
reqmessage-setJMSReplyTo(Tqueue);
reqmessage-setJMSCorrelationID(butter);
	reqmessage-writeString(MsgStr) ; 


producer-send(reqmessage);
	] 



[.Server side .

// server side
public void onMessage(message) {

pstring NCid;
pIDestination NDest;
NCid = message-getJMSCorrelationID();
NDest = message-getJMSReplyTo();
	 


producer = session-createProducer(NDest) ;
reqMessage = session-createBytesMessage() ;
reqMessage-setJMSCorrelationID(NCid-c_str() );
		reqMessage-writeString(respMSG) ;  //respMSG a variable 


producer-send(NDest ,reqMessage);
}
	] 



Am I missing/overdoing anything here?
Please guide me error through. 



		THANKS IN ADVANCE 



Regards,
Navin


Re: Queue hogging by a single consumer.

2006-08-18 Thread Naveen Rawat



Hi James, 

Thanks for the response. 



I achieved the desired behavior for persistent responses and my consumer 
application requires applicability to non-persistent
responses for which I would be trying out your suggestions soon. 

Queries down there. :) 




 Great James 
 Your suggestion is working. A major hurdle seems solved. 
 A little query down there. 
 
 
 
   Hi James, 
   
   Thanks for your response. 
   
   
Are you trying to implement request-response with A, B, C making 
requests on Z and getting the response? Or can A, B, C process any 
message from Z? 
   
   
   Exactly the first case. 
   A, B, C making requests on Z and getting the response from Z 
   
   
   
I'm not sure if your issue is that say A doesn't see the responses for 
its request (if thats the case use either 3 queues, use temporary 
queues for the responses or use a selector and a correlationID on the 
request  response) - or is it that you have a small number of 
responses from Z and they are being hogged by one consumer - in which 
case setting a small prefetch and a round robin dispatch policy will 
fix this. 
   
   
   Its that,  A doesn't see the responses for its requests made. 
   
   I would really appreciate if I can get some help stuff on - 
   1) Creating, destroying and maintaining data in temporary queues. 
   2) Setting selector and correlationID in messages. 
  
  Details here 
  
  http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html 
  
  for 1) just call session.createTemporaryQueue() and set that queue on 
  the Message.setJMSReplyTo() property so that services can reply to 
  your temporary queue. They are deleted when A terminates so there's no 
  issue with maintaining data. 
  
  for 2) just add a JMSCorrelationID() to the request messages you send 
  as requests. You can then use a selector such as JMSCorrelationID = 
  'abc' on the consumer for responses so that responses are filtered to 
  only return A's results etc 
 
 
 I went for this (2nd) one. Even though now a result is obtained, I would 
 like to ask which one approach is more favoured by you. 
 Is it the temporary queues overhead matter that makes 2nd score over 1st? 
 Any other reason please tell.  

The main difference is, do you want the response to be persistent. 
e.g. if A dies and comes back again later - do you want it to resume 
processing old results? In which case use a persistent queue and 
correlation IDs. If the responses are transient then use a temporary 
queue so the old messages get discarded by the broker when A dies.  





You suggested using correlation ID (with persistent queues) for responses to 
be persistent and I did it with Group ID following  the 


documents -
http://incubator.apache.org/activemq/message-groups.html
	http://incubator.apache.org/activemq/how-do-message-groups-compare-to-selec 
tors.html 

What I have done in code is - 


[..A/B/C  Senders...
. . . . . . . . .
// Consumer part that reads the responses from a persistent queue.
consumer = session-createConsumer(queue, JMSXGroupID = 'cheese') ;
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .   
message-setJMSXGroupID(cheese) ;
producer-send(message) ;
	] 



[..Z Consumer Application (OnMessage).
. . . . . . . . .
pstring NGid;
NGid = message-getJMSXGroupID();
. . . . . . . . .
. . . . . . . . .
reqMessage-setJMSXGroupID(NGid-c_str() );
. . . . . . . . .
producer-send(reqMessage);
	] 




Is my approach right? Please correct me. 

A bit conerned if my approach equally enable my consumer application 
correctly identify to which remote sender the response is 

sent? 

What is the implementation difference between GroupID and CorrelationID? 





		THANKS IN ADVANCE 


Regards,
Navin


Re: Queue hogging by a single consumer.

2006-08-18 Thread James Strachan

That sounds fine - it doesn't really matter what header you use as the
'correlation token', you could make up your own header if you wish.

Though the reason I said to use JMSCorrelationID was that most well
behaving JMS services should always copy the JMSCorrelationID from any
incoming message and apply it to the outbound message. So using
JMSCorrelationID is more loosely coupled  should work with any JMS
service.

In this case on the client side (A, B, C) there is no real gain in
using Message Groups - which are designed to perform sticky load
balancing of requests - since you are already using a selector meaning
that there will be only 1 consumer of a message so nothing to load
balance. You might want to use message groups on the service side of
things - the Z - so that you could perform sitcky load balancing if
you have a pool of Z consumers.

On 8/18/06, Naveen Rawat [EMAIL PROTECTED] wrote:



Hi James,

Thanks for the response.


I achieved the desired behavior for persistent responses and my consumer
application requires applicability to non-persistent
responses for which I would be trying out your suggestions soon.

Queries down there. :)



  Great James
  Your suggestion is working. A major hurdle seems solved.
  A little query down there.
 
 
 
Hi James,
   
Thanks for your response.
   
   
 Are you trying to implement request-response with A, B, C making
 requests on Z and getting the response? Or can A, B, C process any
 message from Z?
   
   
Exactly the first case.
A, B, C making requests on Z and getting the response from Z
   
   
   
 I'm not sure if your issue is that say A doesn't see the responses for
 its request (if thats the case use either 3 queues, use temporary
 queues for the responses or use a selector and a correlationID on the
 request  response) - or is it that you have a small number of
 responses from Z and they are being hogged by one consumer - in which
 case setting a small prefetch and a round robin dispatch policy will
 fix this.
   
   
Its that,  A doesn't see the responses for its requests made.
   
I would really appreciate if I can get some help stuff on -
1) Creating, destroying and maintaining data in temporary 
queues.
2) Setting selector and correlationID in messages.
  
   Details here
  
   
http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html
  
   for 1) just call session.createTemporaryQueue() and set that queue on
   the Message.setJMSReplyTo() property so that services can reply to
   your temporary queue. They are deleted when A terminates so there's no
   issue with maintaining data.
  
   for 2) just add a JMSCorrelationID() to the request messages you send
   as requests. You can then use a selector such as JMSCorrelationID =
   'abc' on the consumer for responses so that responses are filtered to
   only return A's results etc
 
 
  I went for this (2nd) one. Even though now a result is obtained, I would
  like to ask which one approach is more favoured by you.
  Is it the temporary queues overhead matter that makes 2nd score over 1st?
  Any other reason please tell.

 The main difference is, do you want the response to be persistent.
 e.g. if A dies and comes back again later - do you want it to resume
 processing old results? In which case use a persistent queue and
 correlation IDs. If the responses are transient then use a temporary
 queue so the old messages get discarded by the broker when A dies.




You suggested using correlation ID (with persistent queues) for responses to
be persistent and I did it with Group ID following  the

documents -
http://incubator.apache.org/activemq/message-groups.html

http://incubator.apache.org/activemq/how-do-message-groups-compare-to-selec
tors.html

What I have done in code is -

[..A/B/C  Senders...
. . . . . . . . .
// Consumer part that reads the responses from a persistent queue.
consumer = session-createConsumer(queue, JMSXGroupID = 'cheese') ;
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
message-setJMSXGroupID(cheese) ;
producer-send(message) ;
]


[..Z Consumer Application (OnMessage).
. . . . . . . . .
pstring NGid;
NGid = message-getJMSXGroupID();
. . . . . . . . .
. . . . . . . . .
reqMessage-setJMSXGroupID(NGid-c_str() );
. . . . . . . . .
producer-send(reqMessage);
]



Is my approach right? Please correct me.

A bit conerned if my approach equally enable my consumer application
correctly identify to which remote sender the response is

sent?

What is the implementation 

Re: Queue hogging by a single consumer.

2006-08-18 Thread Naveen Rawat


Hi James, 



Thanks for the information. I liked your reasoning enough that I am now 
using CorrelationID in place of GroupID with equal ease. The issue that 
caused the rising of this mail seems solved for the moment. 

But, 

I m facing certain problems using temporary queues for transient responses. 
Initiating this issue with a new context. See you there :) 



That sounds fine - it doesn't really matter what header you use as the 
'correlation token', you could make up your own header if you wish.  

Though the reason I said to use JMSCorrelationID was that most well 
behaving JMS services should always copy the JMSCorrelationID from any 
incoming message and apply it to the outbound message. So using 
JMSCorrelationID is more loosely coupled  should work with any JMS 
service.  

In this case on the client side (A, B, C) there is no real gain in 
using Message Groups - which are designed to perform sticky load 
balancing of requests - since you are already using a selector meaning 
that there will be only 1 consumer of a message so nothing to load 
balance. You might want to use message groups on the service side of 
things - the Z - so that you could perform sitcky load balancing if 
you have a pool of Z consumers. 



		THANKS IN ADVANCE 



Regards,
Navin


Re: Queue hogging by a single consumer.

2006-08-17 Thread Naveen Rawat
Hi James, 

Thanks for your response. 



Are you trying to implement request-response with A, B, C making 
requests on Z and getting the response? Or can A, B, C process any 
message from Z? 



Exactly the first case.
A, B, C making requests on Z and getting the response from Z 




I'm not sure if your issue is that say A doesn't see the responses for 
its request (if thats the case use either 3 queues, use temporary 
queues for the responses or use a selector and a correlationID on the 
request  response) - or is it that you have a small number of 
responses from Z and they are being hogged by one consumer - in which 
case setting a small prefetch and a round robin dispatch policy will 
fix this. 



Its that,  A doesn't see the responses for its requests made. 


I would really appreciate if I can get some help stuff on -
1) Creating, destroying and maintaining data in temporary queues.
	2) Setting selector and correlationID in messages. 




On 8/17/06, Naveen Rawat [EMAIL PROTECTED] wrote: 
 
 Hi all :) 
 
 I am working with the binary version of ActiveMQ 4.0 broker and trying out 
 the openwire cpp apis for asynchronous messaging. 
 [https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0/openw 
 ire-cpp] 
 
 
 
 I wonder if I m resurrecting the mummies of issues already burnt. 
 
 
 
 I am trying out having 3 consumers A, B and C listening on the same queue. 
 What I am trying to do is - 
 
 A, B, C sending on Q1, and consuming Z's response on Q2 
 Consumer Z listening on Q1, responding back on Q2. 
 
 like this - 
 A/B/CQ1ZQ2A/B/C 
 
 
 Listening/responding to a single consumer is working well at present. BUT 
 broker is spoofing up the responses from Z to the simultaneous consumers 
 (either 2 or all three). Response for one consumer (A) is going to any of 
 the other consumer (B/C). Same is happening for other consumers. Being 
 prefetch size preset to 1000, the consumer that first manages session with 
 the broker on a queue is getting all the messages (and if it gets 
 terminated, the following one hogs the all and so on.) . 
 
 As I m at presently testing, setting prefetch size to less (say 1), even 
 dont solves the purpose as not giving it frequest quick requests (man Vs 
 machine). Moreover as the hogging consumer is reading and acknowledging all 
 the responses, the prefetch size of even 1 is not surpassed. 
 
 I tried out with no success the way of grid processing of messages (using 
 MessageGroups) as suggested in 
 http://activemq.org/site/how-do-i-preserve-order-of-messages.html 
 Code relevant of this is as follows - 
 
 [A/B/C 
 producer = session-createProducer(Q1) ; 
 producer-setPersistent(true) ; 
 message = session-createBytesMessage() ; 
 message-setJMSXGroupID(cheese) ; 
 message-writeString(Hello World) ; 
 producer-send(message); 
 .] 
 
 
 [ .Z ' s OnMessage(message)... 
 pstring NGid; 
 NGid = message-getJMSXGroupID(); 
 producer = session-createProducer(Q2) ; 
 producer-setPersistent(true) ; 
 reqMessage = session-createBytesMessage() ; 
 reqMessage-setJMSXGroupID(NGid-c_str() ); 
 reqMessage-writeString(R E C E I V E D) ;//response string 
 producer-send(reqMessage); 
 .] 
 
 Is there anymore needed in the code that I m loosing? 
 
 
 I come to know that there are certain issues yet not resolved pertaining to 
 the prefetch buffer initial size. Correct me please. 
 Will manipulation of prefetch buffer size help my cause? Please suggest a 
 way otherwise. 
 



THANKS IN ADVANCE

Regards,
Navin



Re: Queue hogging by a single consumer.

2006-08-17 Thread James Strachan

On 8/17/06, Naveen Rawat [EMAIL PROTECTED] wrote:

Hi James,

Thanks for your response.


 Are you trying to implement request-response with A, B, C making
 requests on Z and getting the response? Or can A, B, C process any
 message from Z?


Exactly the first case.
A, B, C making requests on Z and getting the response from Z



 I'm not sure if your issue is that say A doesn't see the responses for
 its request (if thats the case use either 3 queues, use temporary
 queues for the responses or use a selector and a correlationID on the
 request  response) - or is it that you have a small number of
 responses from Z and they are being hogged by one consumer - in which
 case setting a small prefetch and a round robin dispatch policy will
 fix this.


Its that,  A doesn't see the responses for its requests made.

I would really appreciate if I can get some help stuff on -
1) Creating, destroying and maintaining data in temporary queues.
2) Setting selector and correlationID in messages.


Details here

http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html

for 1) just call session.createTemporaryQueue() and set that queue on
the Message.setJMSReplyTo() property so that services can reply to
your temporary queue. They are deleted when A terminates so there's no
issue with maintaining data.

for 2) just add a JMSCorrelationID() to the request messages you send
as requests. You can then use a selector such as JMSCorrelationID =
'abc' on the consumer for responses so that responses are filtered to
only return A's results etc

The contract of Z whichever option you go with is the to copy the
JMSCorrelationID property from the request to the response message and
send the response message to the request.getJMSReployTo() destination

--

James
---
http://radio.weblogs.com/0112098/


Re: Queue hogging by a single consumer.

2006-08-17 Thread Naveen Rawat
Thanks James. 

Thanks for the response 

I will try out your suggestions and get back to you soon. 

 Hi James, 
 
 Thanks for your response. 
 
 
  Are you trying to implement request-response with A, B, C making 
  requests on Z and getting the response? Or can A, B, C process any 
  message from Z? 
 
 
 Exactly the first case. 
 A, B, C making requests on Z and getting the response from Z 
 
 
 
  I'm not sure if your issue is that say A doesn't see the responses for 
  its request (if thats the case use either 3 queues, use temporary 
  queues for the responses or use a selector and a correlationID on the 
  request  response) - or is it that you have a small number of 
  responses from Z and they are being hogged by one consumer - in which 
  case setting a small prefetch and a round robin dispatch policy will 
  fix this. 
 
 
 Its that,  A doesn't see the responses for its requests made. 
 
 I would really appreciate if I can get some help stuff on - 
 1) Creating, destroying and maintaining data in temporary queues. 
 2) Setting selector and correlationID in messages.  

Details here  

http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html  

for 1) just call session.createTemporaryQueue() and set that queue on 
the Message.setJMSReplyTo() property so that services can reply to 
your temporary queue. They are deleted when A terminates so there's no 
issue with maintaining data.  

for 2) just add a JMSCorrelationID() to the request messages you send 
as requests. You can then use a selector such as JMSCorrelationID = 
'abc' on the consumer for responses so that responses are filtered to 
only return A's results etc  

The contract of Z whichever option you go with is the to copy the 
JMSCorrelationID property from the request to the response message and 
send the response message to the request.getJMSReployTo() destination 





Regards,
Navin


Re: Queue hogging by a single consumer.

2006-08-17 Thread James Strachan

On 8/17/06, Naveen Rawat [EMAIL PROTECTED] wrote:

Great James
Your suggestion is working. A major hurdle seems solved.
A little query down there.



  Hi James,
 
  Thanks for your response.
 
 
   Are you trying to implement request-response with A, B, C making
   requests on Z and getting the response? Or can A, B, C process any
   message from Z?
 
 
  Exactly the first case.
  A, B, C making requests on Z and getting the response from Z
 
 
 
   I'm not sure if your issue is that say A doesn't see the responses for
   its request (if thats the case use either 3 queues, use temporary
   queues for the responses or use a selector and a correlationID on the
   request  response) - or is it that you have a small number of
   responses from Z and they are being hogged by one consumer - in which
   case setting a small prefetch and a round robin dispatch policy will
   fix this.
 
 
  Its that,  A doesn't see the responses for its requests made.
 
  I would really appreciate if I can get some help stuff on -
  1) Creating, destroying and maintaining data in temporary queues.
  2) Setting selector and correlationID in messages.

 Details here

 
http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html

 for 1) just call session.createTemporaryQueue() and set that queue on
 the Message.setJMSReplyTo() property so that services can reply to
 your temporary queue. They are deleted when A terminates so there's no
 issue with maintaining data.

 for 2) just add a JMSCorrelationID() to the request messages you send
 as requests. You can then use a selector such as JMSCorrelationID =
 'abc' on the consumer for responses so that responses are filtered to
 only return A's results etc


I went for this (2nd) one. Even though now a result is obtained, I would
like to ask which one approach is more favoured by you.
Is it the temporary queues overhead matter that makes 2nd score over 1st?
Any other reason please tell.


The main difference is, do you want the response to be persistent.
e.g. if A dies and comes back again later - do you want it to resume
processing old results? In which case use a persistent queue and
correlation IDs. If the responses are transient then use a temporary
queue so the old messages get discarded by the broker when A dies.


--

James
---
http://radio.weblogs.com/0112098/


Queue hogging by a single consumer.

2006-08-17 Thread Naveen Rawat


Hi all :) 

I am working with the binary version of ActiveMQ 4.0 broker and trying out 
the openwire cpp apis for asynchronous messaging.
[https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0/openw 
ire-cpp] 




I wonder if I m resurrecting the mummies of issues already burnt. 




I am trying out having 3 consumers A, B and C listening on the same queue.
What I am trying to do is - 


A, B, C sending on Q1, and consuming Z's response on Q2
	Consumer Z listening on Q1, responding back on Q2. 


like this -
A/B/CQ1ZQ2A/B/C
	 

Listening/responding to a single consumer is working well at present. BUT 
broker is spoofing up the responses from Z to the simultaneous consumers 
(either 2 or all three). Response for one consumer (A) is going to any of 
the other consumer (B/C). Same is happening for other consumers. Being 
prefetch size preset to 1000, the consumer that first manages session with 
the broker on a queue is getting all the messages (and if it gets 
terminated, the following one hogs the all and so on.) . 

As I m at presently testing, setting prefetch size to less (say 1), even 
dont solves the purpose as not giving it frequest quick requests (man Vs 
machine). Moreover as the hogging consumer is reading and acknowledging all 
the responses, the prefetch size of even 1 is not surpassed. 

I tried out with no success the way of grid processing of messages (using 
MessageGroups) as suggested in

http://activemq.org/site/how-do-i-preserve-order-of-messages.html
Code relevant of this is as follows - 


[A/B/C
producer = session-createProducer(Q1) ;
producer-setPersistent(true) ;
message = session-createBytesMessage() ;
message-setJMSXGroupID(cheese) ;
message-writeString(Hello World) ;
producer-send(message);
	.] 



[ .Z ' s OnMessage(message)...
pstring NGid;
NGid = message-getJMSXGroupID();
producer = session-createProducer(Q2) ;
producer-setPersistent(true) ;
reqMessage = session-createBytesMessage() ;
reqMessage-setJMSXGroupID(NGid-c_str() );
reqMessage-writeString(R E C E I V E D) ;   //response string
producer-send(reqMessage);
	.] 

Is there anymore needed in the code that I m loosing? 



I come to know that there are certain issues yet not resolved pertaining to 
the prefetch buffer initial size. Correct me please.
Will manipulation of prefetch buffer size help my cause? Please suggest a 
way otherwise. 

HELP ME.. 



			THANKS IN ADVANCE 


Regards,
Navin