[
https://issues.apache.org/jira/browse/QPID-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984725#comment-15984725
]
Alex Rudyy commented on QPID-7639:
----------------------------------
Here is the transcript of IM conversation with discussion of the topic
{noformat}
(11:36:07) orudyy: rgodfrey: Hi Rob,
(11:36:07) orudyy: Re your comments for QPID-7639: I agree that method name
AbstractAMQPSession#getMaxUncommittedInMemorySize() gives an impression that it
is a limit per session and the correct name would be something like
#getMaxUncommittedInMemorySizePerTransaction(). Thus, the current name of the
method is indeed misleading. I will fix that. Is it what I meant in your
comment? I just would like to clarify that I correctly understood your comment.
Did you mean something else?
(11:38:42) rgodfrey: So the question is - what is the intent?
(11:38:59) rgodfrey: Is the intent that we have a limit per session / per
connection… or that we have a per transaction limit
(11:39:23) rgodfrey: if the limit is per transaction why is the limit held on
the session and not the connection (or at the vhost level)?
(11:40:14) rgodfrey: Basically the issue is that AMQP 1.0 works differently to
the other protocols… so either we need to redefine what the limit means, or the
implementation for 1.0 actually has to be per session, in which case the
accounting logic needs to be more complex
(11:46:40) rgodfrey: I actually feel like the 0-x implementations are wrong
too… they are implementing a maximum uncommitted size *per session* but the
context variable naming (and to a certain extent, common sense) would imply
that the limit should be per connection
(11:46:56) orudyy: Ah... I see you point. The original intent was just to have
the same functionality as in 0.x
(11:47:54) rgodfrey: yeah - which the current change doesn't give… but I think
we should probably first define what the desired functionality is, and then
work out how it should be implemented in 0-x and 1-0
(11:50:06) orudyy: I see. Do you think that for 1-0 the limit should apply per
connection?
(11:50:33) rgodfrey: I think all protocols should do the same thing :-)
(11:51:13) rgodfrey: per txn doesn't really make sense… per ssn was convenient
for 0-x but I think that per-connection is probably the most sensible thing to
do across all protools
(11:58:38) orudyy: I think it make sense to have limit per connection for all
protocols. Additionally, I would add another limit(s) for VH and Broker, in
order to protect the case when multiple connections accumulativly could
consume direct memory but messages on none of them would breach the connection
threshold. What do you think on introduction of VH and Broker limits?
(11:59:25) rgodfrey: I agree VH/Broker limits would make sense, but would
probably raise them as a separate JIRA to be separately prioritized
(12:00:08) k-wall: yeah - Alex correctly identifies an existing problme
(12:00:26) orudyy: Ok. I'll raise the JIRAs for VH and Broker limits and I will
repurpose the existing JIRA to implement connection limit
(12:00:53) k-wall: thanks Alex - so that would be a change to all protocols.
(12:01:01) orudyy: yeap
(12:01:11) rgodfrey: k-wall: yes - that would be a change to the undocumented
behaviour of all protocols :-)
(12:01:19) rgodfrey: (hint - we should probably document this :-) )
(12:02:12) k-wall: :)
(12:03:03) k-wall: I wouldn’t bother trying to retain the existing behaviour of
the existing context var. Few (noone) will be configuring this and we can
mention in the release notes
(12:03:41) rgodfrey: yeah - I agree - given that it was previously
undocumented, I think it is fine to just define the new behaviour and document
the new behaviour in release notes
{noformat}
> Implement large transaction guard restricting direct memory consumption by
> messages from uncommitted transactions on the connection
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7639
> URL: https://issues.apache.org/jira/browse/QPID-7639
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Assignee: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> The current implementation of AMQP 0-x layers restrict the memory consumption
> by messages from uncommitted transactions on the session level.
> We need to change the existing implementations to apply the limit per
> connection and add implementation for AMQP 1.0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
