Re: [VOTE] Release Maven Resolver version 1.5.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Maven Resolver version 1.5.0

Elliotte Rusty Harold
I don't fully grok the issue at hand and do not feel comfortable
deciding between whether this works or not. When I try to write
complicated multithreaded code that needs to synchronize between
threads, devs who truly understand this usually find bugs in my work
without looking very hard.

It would be safest for you and Tibor to resolve this before the plugin
is released. If that doesn't happen, we can look for a real
multi-threading expert (not me) to way in on this.


On Sun, Jul 19, 2020 at 3:52 PM Michael Osipov <[hidden email]> wrote:

>
> Am 2020-07-18 um 19:17 schrieb Elliotte Rusty Harold:
> > Michael,
> >
> > Could you address Tibor's concerns about your solution to [MRESOLVER-123]?
> >
> > https://github.com/apache/maven-resolver/pull/65
>
> So I did, the code complies to the contract of the SynContextFactory
> interface as well as to the contract of ReentrantReadWriteLock. I truly
> don't understand Tibor's concerns. He questions the design of
> SyncContextFactory, but this is the wrong forum to discuss it. It should
> be separate issue.
>
> Do you have any concerns since you approved the PR?
>
> M
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Maven Resolver version 1.5.0

michaelo
Am 2020-07-19 um 20:40 schrieb Elliotte Rusty Harold:
> I don't fully grok the issue at hand and do not feel comfortable
> deciding between whether this works or not. When I try to write
> complicated multithreaded code that needs to synchronize between
> threads, devs who truly understand this usually find bugs in my work
> without looking very hard.
>
> It would be safest for you and Tibor to resolve this before the plugin
> is released. If that doesn't happen, we can look for a real
> multi-threading expert (not me) to way in on this.

This is strange, there has been a discussions for weeks in JIRA, no
other committer chimed in. I have created a PR, yet you were the only
one to approve. I have even asked on the ML if there is an objection,
none came. Now that I have merged everything and triggered the release
people start complaining that this is faulty, why don't do you do this
and that? Seriously? I gave the community plenty of time to express
their objections and even provide better solutions, but nothing has
happened. Unless Tibor can provide me explicit code what makes the given
implementation better/correct according to SyncContextFactory, I see no
easier way to provide a fix. Even worse that we didn't care for years
about this annoying bug, but no one stood up to fix this in some fashion.
After this simple fix I wanted to look into a Redisson-based solution
for true multiprocess concurrency because it does provide all necessary
locks, but frankly I won't spend any of my free time on it.

M

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]