Hi Pavel,

Thanks for the reply.

I'm using C++ broker with C++ clients.

Here is an example of what I'm trying to say:
I have a publisher that will send message #1 to news.weather and message
#2 to news.economy. If I only have one client and this client is only
listening news.weather, sending #2 would not be necessary.
This is what's happening but multiplied by thousands, so my sender is
occupying 10MB/s of my network, but 99% of the messages will be
discarded because no one is listening.

Best regards,
Bruno

On Wed, 2012-04-18 at 06:54 -0400, Pavel Moravec wrote:
> Hi Bruno,
> what broker (C++ / Java) and client (C++ / Java / Python / ..) are you using?
> 
> Generally, I would recommend creating more AMQP sessions where messages to 
> potentially blocked queues are sent on one session, time to time synchronize 
> those sessions and use producer flow control that would block sender from 
> sending messages to a queue occupied by 80% (default value) or more.
> 
> Kind regards,
> Pavel
> 
> 
> ----- Original Message -----
> > From: "Bruno Matos" <[email protected]>
> > To: [email protected]
> > Sent: Wednesday, April 18, 2012 12:19:52 PM
> > Subject: Reduce Sender traffic
> > 
> > Hi,
> > 
> > I have a sender that publishes about 10MB of messages per second for
> > different topics. Only about 1% of that traffic is delivered because
> > only about 1% of the topics are bound at a time. Is it possible, or
> > would it be desirable, that the sender only effectively send the
> > messages for witch there is a bound queue?
> > 
> > Tia.
> > 
> > --
> > Bruno Matos
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

-- 
Bruno Matos


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to