[
https://issues.apache.org/jira/browse/GEODE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269174#comment-17269174
]
ASF GitHub Bot commented on GEODE-8846:
---------------------------------------
jvarenina commented on pull request #5927:
URL: https://github.com/apache/geode/pull/5927#issuecomment-764504234
> > Hi reviewers,
> > I'm not sure in this solution anymore. Now, I think that it would be
better to change uniqID from AtomicInteger to AtomicLong. The Integer.MAX_VALUE
is just to small, and because of that, uniqID would overflow to often with this
solution. That could possibly cause conflict between new transactions and old
transactions (that are suspended or hang) with same uniqID.
> > It would require much bigger impact on the code to use AtomicLong. Also,
It would be necessary to preserve backward compatibility with the old client
that would still use integer for the uniqID.
> > What do you think? Do you maybe see any possible issues with changing
AtomicInteger to AtomicLong?
>
> The integer is enough for GEODE use cases. Geode transaction is designed
to be a small, short lived one, as it takes resources to perform a transaction
(use TXState). I do not think a collision is likely scenario for geode user
applications. The transaction should be committed if overflow ever occurs,
otherwise it would be a user error. And geode does have default 3 minutes (if
inactive) for client to work on a transaction before expiring the transaction.
> this.transactionTimeToLive = Integer
> .getInteger(GeodeGlossary.GEMFIRE_PREFIX +
"cacheServer.transactionTimeToLive", 180);
> There is no need to change to AtomicLong.
Your are completely right. Thank you on this clarification.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Transaction commit fail when uniqueID integer overflow to negative value
> ------------------------------------------------------------------------
>
> Key: GEODE-8846
> URL: https://issues.apache.org/jira/browse/GEODE-8846
> Project: Geode
> Issue Type: Bug
> Components: client/server
> Affects Versions: 1.13.0, 1.13.1
> Reporter: Jakov Varenina
> Assignee: Jakov Varenina
> Priority: Major
> Labels: pull-request-available
>
> When client increments *uniqId* above Integer.MAX_VALUE (2147483647) then due
> to memory overflow the *uniqId* is set to negative value Integer.MIN_VALUE
> (-2147483648). TransactionID (uniqId) is sent to the server as a part of
> transaction message.
> {code:java}
> public class TXManagerImpl implements CacheTransactionManager,
> MembershipListener {
> ...
> // The unique transaction ID for this Manager
> private final AtomicInteger uniqId;
> ....
> TXId id = new TXId(this.distributionMgrId, this.uniqId.incrementAndGet());
> ....
> {code}
> Currently server will interpret any negative value of transactionID (uniqID)
> as non-transactional traffic. Please notice that getTransactionID() actually
> retrieves uniqID value that is set by client.
> {code:java}
> /**
> * checks to see if this thread needs to masquerade as a transactional
> thread. clients after
> * GFE_66 should be able to start a transaction.
> *
> * @return true if thread should masquerade as a transactional thread.
> */
> protected boolean shouldMasqueradeForTx(Message clientMessage,
> ServerConnection serverConnection) {
> return
> serverConnection.getClientVersion().isNotOlderThan(KnownVersion.GFE_66)
> && clientMessage.getTransactionId() > TXManagerImpl.NOTX; // ---> NOTX
> is equal -1
> }
> {code}
> After overflow happens all subsequent commit actions from the client are
> rejected with exception:
> [vm0] [fatal 2021/01/14 15:28:41.967 CET <ServerConnection on port 39093
> Thread 2> tid=0x52] Server connection from
> [identity(192.168.90.23(29826:loner):48210:6c694c01,connection=1; port=48212]
> : Unexpected Error on server
> [vm0] org.apache.geode.InternalGemFireError
> [vm0] at org.apache.geode.internal.Assert.throwError(Assert.java:91)
> [vm0] at org.apache.geode.internal.Assert.assertTrue(Assert.java:55)
> [vm0] at
> org.apache.geode.internal.cache.tier.sockets.command.CommitCommand.cmdExecute(CommitCommand.java:82)
> [vm0] at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> [vm0] at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> [vm0] at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> [vm0] at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1214)
> [vm0] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm0] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm0] at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:691)
> [vm0] at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> [vm0] at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
