activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mtaylor <...@git.apache.org>
Subject [GitHub] activemq-artemis pull request #690: Amqp hard soft limits
Date Wed, 03 Aug 2016 12:58:56 GMT
Github user mtaylor commented on a diff in the pull request:

    https://github.com/apache/activemq-artemis/pull/690#discussion_r73333330
  
    --- Diff: artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/proton/plug/ProtonSessionIntegrationCallback.java
---
    @@ -351,18 +353,35 @@ public void serverSend(final Receiver receiver,
           recoverContext();
     
           PagingStore store = manager.getServer().getPagingManager().getPageStore(message.getAddress());
    -      if (store.isFull() && store.getAddressFullMessagePolicy() == AddressFullMessagePolicy.BLOCK)
{
    -         ErrorCondition ec = new ErrorCondition(AmqpError.RESOURCE_LIMIT_EXCEEDED, "Address
is full: " + message.getAddress());
    -         Rejected rejected = new Rejected();
    -         rejected.setError(ec);
    -         delivery.disposition(rejected);
    -         connection.flush();
    +      if (store.isRejectingMessages()) {
    +         // We drop pre-settled messages (and abort any associated Tx)
    +         if (delivery.remotelySettled()) {
    +            if (serverSession.getCurrentTransaction() != null) {
    +               rollbackCurrentTX(false);
    +
    +               // Spec requires closure of coordinator link on rejection of presettled
messages within a tx
    --- End diff --
    
    Updating here, so we can track the conversation.  There spec outlines 2 options:  If a
pre-settled message is sent during a tx that the broker can't handle it should either (in
laymans terms):
    
    1. Close the coordinator link.
    2. Set the transaction to rollback only.
    
    Given the 2 options I went with 1. Close the coordinator link.  
    
    The benefit of 1. is that the client knows the Tx failed early on and can stop processing
it.  Robbie mentioned that a long running tx is unlikely and probably the client already sent
everything + the commit.
    
    The benefit of 2. is that the client does not need to re establish the coordinator link
if the tx fails in this scenario.  Robbie mentions that clients may support this option.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message