[
https://issues.apache.org/jira/browse/IGNITE-13383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186328#comment-17186328
]
Aleksey Plekhanov commented on IGNITE-13383:
--------------------------------------------
[~zstan], I don't think this ticket should be fixed at all. Both "improvements"
didn't look like improvements.
1. Concurrent structures were introduced for a reason, they prevent memory
leaks (https://github.com/apache/ignite/pull/6734#pullrequestreview-278104733).
Their performance worth nothing compared to other logic (perhaps micropercents
of total request time). Why should we sacrifice correctness for this?
2. What's wrong with the channel check on the client's side? It's a "fail-fast"
approach. With your change client will get the same result, but should send
request to the server to get an error. Moreover, you introduce memory leak
again on the server-side (current connection context has reference to the
{{ses}}, which has reference to the previous connection context, which has
reference to the {{ses}} and so on). And it doesn't protect from txId
intersection. For example, you have 2 clients, both connects to the server,
initial txId for first will be 0, initial txId for the second will be 1, then
first creates three transactions (txId=1, txId=2, txId=3) and lost connection,
after reconnect initial txId will be 2, and next started transaction will
intersect old transactions by id. I think simple and reasonable check on
client-side is better than complex, unclear, and error-prone logic on
server-side.
> Java thin client improvements: channel reconnect and redundant concurrency
> structures replacement.
> --------------------------------------------------------------------------------------------------
>
> Key: IGNITE-13383
> URL: https://issues.apache.org/jira/browse/IGNITE-13383
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
> Affects Versions: 2.8.1
> Reporter: Stanilovsky Evgeny
> Assignee: Stanilovsky Evgeny
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I found that {code:java}ConcurrentHashMap{code} and
> {code:java}AtomicLong{code} are redundant in java thin client code, yes i fix
> tests a bit but i can`t see any contradictions with thick client behavior
> here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
