[jira] [Commented] (QPID-7646) [Java Broker] fix AbstractAMQPSession#getLocalTransactionOpen to support values > 1

["Keith Wall (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217167#comment-16217167 ] 

Keith Wall commented on QPID-7646:
----------------------------------

I think it is useful to think first about the use-cases for the transaction statistics on the model. I can think of two:

# As an operator, I need to be able to determine if a connection is using transactions for messaging. The failure to use transactions is a common application error.  Application owners tend to report "message loss" from the messaging layer.
# As an operator or developer, applications that begin transactional work and then fail to commit can be a difficult problem to diagnose.  It would be desirable if the Broker could help reveal this to me.

Currently on the model we have the following transaction related statistics:

{{Session#localTransactionBegins}}  (cumulative)
{{Session#localTransactionRollbacks}} (cumulative)
{{Session#localTransactionOpen}} (point in time - number of open transactions at this moment)
{{Session#getTransactionStartTime}} (time when the current *producing* store transaction began)
{{Session#getTransactionUpdateTime}} (time when the current *producing* store  transaction last received new work)

and attributes:

QueueManagingVirtualHost#getStoreTransactionIdleTimeoutClose
QueueManagingVirtualHost#getStoreTransactionIdleTimeoutWarn
QueueManagingVirtualHost#getStoreTransactionOpenTimeoutClose
QueueManagingVirtualHost#getStoreTransactionOpenTimeoutWarn

The last two statistics were influenced by implementation - specifically how the Broker uses the store. For a producing session the message store transaction is opened as the first message arrives and continues until the producing session is committed.  For consuming sessions, the change of state is a memory until the consuming session is committed, at which point we have a single short lived store transaction.

For AMQP 0-9..0-10 transactions are scoped to channels or sessions.  In AMQP 1.0, this is not the case.  A single transaction can span multiple sessions.   This necessitates a re-modelling.

h1. Proposal - Model changes - for v7.

# Introduce QueueManagingVirtualHost#(TransactedEnqueuedMessages|TransactedDequeuedMessages) and 
                   Connection#(TransactedEnqueuedMessages|getTransactedEnqueuedMessages)
# Replace Session#getTransactionStartTime and #getTransactionUpdateTime with Connection#getOldestTransactionStartTime 
# Move Session#localTransaction(Begins|Rollback|Open) from Session to Connection  (do we actually need these?)

The transactedEnqueuedMessages/transactedDequeuedMessages statistics allows an operator to determine if a application is using transactions or not.  He does this by comparing the transactedEnqueuedMessages with the  totalEnqueuedMessages etc.   If the transactedEnqueuedMessages is lower, he can infer that transactions are not universally in use on that connection or virtualhost.

h1. Future work - not v7 - TransactionTimeout for AMQP 1.0:

* AMQConnection_1_0#getOpenTransactions is unused - push up and change the return type to Iterator<ServerTransaction>
* For 0-9 and 0-10 getOpenTranactions will simply expose the LocalTransaction associated with each session of the connection.
* Refactor the TransactionTimeoutTicker to be associated with a connection instead of session. It will call AMQConnection#getOpenTransactions.
* How will the transaction timeout close the session or connection for 0-9 or 0-10?  Perhaps TransactionTimeoutTicker can have protocol specific implementations allowing it to do the right thing for each protocol.
* For AMQP 1.0 What is the correct way to abort the timed out transaction.  Can we simply close the transaction-coordinator link?  How would client respond to this?





> [Java Broker] fix AbstractAMQPSession#getLocalTransactionOpen to support values > 1
> -----------------------------------------------------------------------------------
>
>                 Key: QPID-7646
>                 URL: https://issues.apache.org/jira/browse/QPID-7646
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>            Reporter: Lorenz Quack
>             Fix For: qpid-java-broker-7.0.0
>
>
> During the review of QPID-7633 it was noted:
> bq. Why do we only return 0 or 1 from AbstractAMQPSession#getLocalTransactionOpen. That seems wrong.
> which was followed up by Rob:
> bq. On getLocalTransactionOpen, I agree that looks very dodgy. In AMQP 0-x the value will only be 0 or 1, but I'm not sure the implementation the we have now is safe. I think the implementations will need to define this properly (i.e. the calculation will need to be atomic, and the value may be > 1 for AMQP 1.0 )



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org