[rabbitmq-discuss] 答复: something about message priority

[Ernest Staszuk]

I didn't use spring amqp api, so I can not provide you working example.

I use consuming with small timeout (and there is a cost of time - small 
delay,
  not an issue in my case, cpu usage and network fingerprints stays very 
small).
I was also taking advantage of rabbit's java client prefetching (I am 
not sure
if spring implements that). These two combined gave me acceptable 
approximation of priorities.

You could also add to messages own argument (for example myPriority) and 
consume all messages
as they are available (or let's say up to 200 messages or sth), then put 
them in a priority
queue on your application side. And then process them from the head of 
this container (using
dedicated thread). That also may give you acceptable results.

Note that the state of art is as follows: RabbitMQ is a FIFO queue, and 
does not make
use of message priorities today. It could be changed in one of the 
future releases, I don't
know when it may be. As consequence of that you should apply some 
reasonable workaround
which will be acceptable for you or reconsider your needs (maybe you 
don't really need
priorities?) or use something else than RabbitMQ or implement it by 
yourself. By the way
AMQP itself says that "Messages with higher priorities MAY be delivered 
before those with
lower priorities". Following that messages priority in any 
implementation of AMQP may
be not consistent.

Best regards,
Ernest Staszuk





W dniu 2012-07-27 10:50, andy pisze:
> at as you say ,if we are processing 2st queue message as soon as the 
> 1^st queue gets a new message needed to process,how can we switch to 
> process 1^st ? It also means that we should check the amount of 
>  messages in the queue  in order ,I think it will cost much time and 
> machine resource.and could you tell me  how I could  use spring amqp a

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120727/14f9a601/attachment.htm>