[GitHub] [geode] mkevo opened pull request #4085: GEODE-6927 make getThreadOwnedConnection code thread safe

["mkevo (GitHub)" <gi...@apache.org>]

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

- [x] Has your PR been rebased against the latest commit within the target branch (typically `develop`)?

- [x] Is your initial contribution a single, squashed commit?

- [x] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, check Concourse for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.


[ Full content available at: https://github.com/apache/geode/pull/4085 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] pivotal-jbarrett commented on pull request #4085: GEODE-6927 make getThreadOwnedConnection code thread safe

["pivotal-jbarrett (GitHub)" <gi...@apache.org>]

Again without this member being volatile this check may fail and the next statement that does the putIfAbsent could NPE.

Also, checking here again for null seems arbitrary. The member could be `null` anytime in while we are in this method, including after or in the middle of the `putIfAbsent`. If we are trying to make sure the connection gets closed if and when the table goes `null` then this code doesn't do that. Without some synchronization around when the table can go `null` this gets pretty complicated. 

Maybe it is ok for the connection to go into an orphaned map and not get closed?


[ Full content available at: https://github.com/apache/geode/pull/4085 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] bschuchardt commented on issue #4085: GEODE-6927 make getThreadOwnedConnection code thread safe

["bschuchardt (GitHub)" <gi...@apache.org>]

I don't think we should be using the state of a collection as an indication of whether the service is open or closed.  There should be other state that we use to avoid creating a new connection and putting it in the connection map if ConnectionTable is closed.

[ Full content available at: https://github.com/apache/geode/pull/4085 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] pivotal-jbarrett commented on issue #4085: GEODE-6927 make getThreadOwnedConnection code thread safe

["pivotal-jbarrett (GitHub)" <gi...@apache.org>]

> I don't think we should be using the state of a collection as an indication of whether the service is open or closed. There should be other state that we use to avoid creating a new connection and putting it in the connection map if ConnectionTable is closed.

Couldn't agree more! If you think its safe for connection references that race into the map on close to sit there then this is an easy fix. A simple check if the collection is closed after the put completes could accomplish this. The close itself would empty the map and any race on that operation would get cleared up on the back end after the put by checking for closed state and removing the entry just put.

[ Full content available at: https://github.com/apache/geode/pull/4085 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] mkevo commented on pull request #4085: GEODE-6927 make getThreadOwnedConnection code thread safe

["mkevo (GitHub)" <gi...@apache.org>]

Thanks for comments! Can we just do `synchronized(this.threadConnectionMap)` at the start and not use copy to local variable? In this case we don't need always to check if threadConnectionMap is changed as it can be only changed by this thread.

[ Full content available at: https://github.com/apache/geode/pull/4085 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] pivotal-jbarrett commented on pull request #4085: GEODE-6927 make getThreadOwnedConnection code thread safe

["pivotal-jbarrett (GitHub)" <gi...@apache.org>]

`threadConnectionMap` should probably be made volatile as well. 

I am also not a fan of the `cm` variable name. I would prefer `Map threadConnectionMap = this.threadConnectionMap`. Or something more descriptive than `cm`.

[ Full content available at: https://github.com/apache/geode/pull/4085 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org