[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations

2021-04-13 Thread GitBox
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-818693664 > I understand this now, but am not happy with for the following reasons: We have a hard requirement on reentrancy, it is up to the lock to implement that properly. If

[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations

2021-04-13 Thread GitBox
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-818667466 > There is one more thing I do not understand and think that this undermines reentrancy: While I understand that you maintain a concurrent map in `NamedLockFactorySupp

[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations

2021-04-01 Thread GitBox
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-811824284 > A left a few comments, please go through. > > * I have a few more homework to do because I do not fully understand all involved layers with `AdaptedReadWriteLo

[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations

2021-04-01 Thread GitBox
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-811791981 General remark: my personal preference for local variables is to declare them as they are, so `Type variable = new Type()`, in cases when the variable is strictly loca

[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations

2021-04-01 Thread GitBox
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-811791981 General remark: my personal preference for local variables is to declare them as they are, so `T variable = new T()`, in cases when the variable is strictly local scop

[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations

2021-04-01 Thread GitBox
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-811791981 General remark: my personal preference for local variables is to declare them as `T variable = new T()`, in cases when the variable is strictly local scoped. I really

[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations

2020-12-28 Thread GitBox
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-751683148 Howdy @rmannibucau For now I consider both HZ and Redisson as "lab" implementation still, due these: * for HZ to work we either must use deprecated HZ 3.x call

[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations

2020-12-28 Thread GitBox
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-751683148 Howdy @rmannibucau For now I consider both HZ and Redisson as "lab" implementation still, due these: * for HZ to work we either must use deprecated HZ 3.x call

[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations

2020-11-21 Thread GitBox
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-731602192 3 nodes are required for CP only w/ Hazelcast 3.x cluster (RAFT consensus backed structures), and yes, is overkill (but someone may choose to run a "dedicated cluster"