[
https://issues.apache.org/jira/browse/QPID-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217167#comment-16217167
]
Keith Wall edited comment on QPID-7646 at 10/24/17 4:16 PM:
------------------------------------------------------------
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.
h3. Problem
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.
h3. 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.
h3. 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?
was (Author: k-wall):
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.
h2. 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.
h2. 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: [email protected]
For additional commands, e-mail: [email protected]
