You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Alex Rudyy (JIRA)" <ji...@apache.org> on 2017/04/26 12:43:04 UTC
[jira] [Commented] (QPID-7639) Implement large transaction guard
restricting direct memory consumption by messages from uncommitted
transactions on the connection
[ 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org