activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Davies (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (AMQ-349) Misbehaving consumer can affect message delivery to other consumers for a given topic.
Date Mon, 30 Jul 2007 11:41:50 GMT

     [ https://issues.apache.org/activemq/browse/AMQ-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rob Davies reassigned AMQ-349:
------------------------------

    Assignee: Rob Davies

> Misbehaving consumer can affect message delivery to other consumers for a given topic.
> --------------------------------------------------------------------------------------
>
>                 Key: AMQ-349
>                 URL: https://issues.apache.org/activemq/browse/AMQ-349
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 3.1
>         Environment: Solaris, JDK 1.4
>            Reporter: Kevin Yaussy
>            Assignee: Rob Davies
>             Fix For: 5.0.0
>
>
> If you have a supplier publishing to a topic, with two consumers both consuming that
topic, a problem with one of the consumers can eventually stop message flow to the other consumer.
 The consumer-problem is specifically categorized as some sort of freeze-up, such that the
broker eventually blocks on the socket write to that consumer.  The freeze-up could be the
process itself (perhaps a problem with the JVM), the network, or perhaps the machine that
the consumer is running on panics and goes away.
> Once the socket becomes blocked, the broker will queue (upto maxOutstandingMessages)
to the consumer.  The properly behaving consumer continues to receive events at this point.
 However, once the queue size reaches maxOutstandingMessages, the broker (the session dispatcher
thread for the given topic) will block on the PooledExecutor.execute method.  This now prohibits
any further message delivery for the given topic to the properly behaving consumer.
> I'm wondering why the "waitWhenBlocked" policy on the PooledExecutor is used?  These
are NON_PERSISTENT messages, so what would be the problem with potentially using one of the
discard policies, such as "discardOldestWhenBlocked" (or "discardWhenBlocked")?  Seems like
one of these two policies should be used by default, and the "waitWhenBlocked" would be a
configurable option.  Our preference would be to use "discardOldestWhenBlocked".  I changed
TcpTransportServerChannel.java to use "discardOldestWhenBlocked", which gave us our desired
functionality.
> From our point of view, having the broker affect all consumers on behalf of one misbehaving
one is bad.  So, what might we be missing with regards to using "discardOldestWhenBlocked"?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message