Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IGNITE-9410 Thin client transactions support #6734

Closed
wants to merge 7 commits into from

Conversation

@alex-plekhanov
Copy link
Contributor

commented Jul 30, 2019

No description provided.

@alex-plekhanov alex-plekhanov force-pushed the alex-plekhanov:ignite-9410 branch from 64654f4 to 73e1ffd Aug 12, 2019
private final ClientBinaryMarshaller marsh;

/** Current thread transaction. */
private final ThreadLocal<TcpClientTransaction> tx = new ThreadLocal<>();

This comment has been minimized.

Copy link
@pavlukhin

pavlukhin Aug 21, 2019

Contributor

It looks like we have a possible memory leak here. TcpClientTransaction has a reference to TcpClientTransactions which has a reference to ThreadLocal<TcpClientTransaction> tx. If some TcpClientTransactions are not in use anymore but left a value in thread-local that value and TcpClientTransactions instance will never be garbage-collected. Making TcpClientTransaction class static should protect from it.

This comment has been minimized.

Copy link
@alex-plekhanov

alex-plekhanov Aug 22, 2019

Author Contributor

We can't make TcpClientTransaction static, because we need TcpClientTransactions context here.
I don't quite understand how we can get possible leak here. If nobody holds the reference to TcpClientTransactions instance and nobody holds the reference to TcpClientTransaction instances, which were created by this TcpClientTransactions, the only references left outside of garbage objects it's a WeakReference to ThreadLocal from threads which have used this TcpClientTransactions instance. These weak references don't prevent to collect garbage objects.
Did I miss something?

This comment has been minimized.

Copy link
@alex-plekhanov

alex-plekhanov Aug 22, 2019

Author Contributor

Sorry, I got it. There is a weak reference only to ThreadLocal instance, but regular reference to TcpClientTransaction from the thread-local table, so memory leak is possible.
I will try to fix it tomorrow.

This comment has been minimized.

Copy link
@alex-plekhanov

alex-plekhanov Aug 23, 2019

Author Contributor

I've fixed the implementation. Also, I've found and fixed server-side transactions leak (transaction has left in active set after an attempt to end it when it's impossible to resume the transaction).

This comment has been minimized.

Copy link
@pavlukhin

pavlukhin Aug 23, 2019

Contributor

👍

Copy link
Contributor

left a comment

Please see several minor comments.

import org.apache.ignite.internal.binary.BinaryRawReaderEx;
import org.apache.ignite.internal.processors.platform.client.ClientConnectionContext;
import org.apache.ignite.internal.processors.platform.client.ClientResponse;

import java.util.LinkedHashMap;
import java.util.Map;

This comment has been minimized.

Copy link
@isapego

isapego Aug 26, 2019

Contributor

Here and in other places, imports should not be re-ordered. See this page for details: https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-PackageImporting

This comment has been minimized.

Copy link
@alex-plekhanov

alex-plekhanov Aug 27, 2019

Author Contributor

It was wrong formated before this patch: Import should be ordered alphabetically, but packages starting with 'java.' should be declared prior to others.
Now it exactly matches coding guidelines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.