Hi Tamas,
I've been trying the Redisson approach for the last 7 weeks, but my machine
locks up every second or third build for long periods of time 5-20min.
I'm on Ubuntu running the Redis 6.2.6 snap using the Maven 3.8.3 and 3.8.4
wrapper. I followed these instructions to setup
Edit the file *${maven.home}/bin/m2.conf* and after *${maven.conf}/logging*
add *load ${maven.home}/lib/ext/redisson/*.jar*
Create the folder *${maven.home}/lib/ext/redisson/* and populate with
https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-named-locks-redisson/1.7.2/maven-resolver-named-locks-redisson-1.7.2.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.12.1/jackson-annotations-2.12.1.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.12.1/jackson-core-2.12.1.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.12.1/jackson-databind-2.12.1.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/dataformat/jackson-dataformat-yaml/2.12.1/jackson-dataformat-yaml-2.12.1.jar
https://repo1.maven.org/maven2/org/jboss/marshalling/jboss-marshalling/2.0.11.Final/jboss-marshalling-2.0.11.Final.jar
https://repo1.maven.org/maven2/org/jboss/marshalling/jboss-marshalling-river/2.0.11.Final/jboss-marshalling-river-2.0.11.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-buffer/4.1.65.Final/netty-buffer-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-codec/4.1.65.Final/netty-codec-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-codec-dns/4.1.65.Final/netty-codec-dns-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-common/4.1.65.Final/netty-common-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-handler/4.1.65.Final/netty-handler-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-resolver/4.1.65.Final/netty-resolver-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-resolver-dns/4.1.65.Final/netty-resolver-dns-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-transport/4.1.65.Final/netty-transport-4.1.65.Final.jar
https://repo1.maven.org/maven2/org/redisson/redisson/3.15.6/redisson-3.15.6.jar
https://repo1.maven.org/maven2/org/yaml/snakeyaml/1.27/snakeyaml-1.27.jar
Delany
On Fri, 8 Oct 2021 at 10:05, Delany <[email protected]> wrote:
> Thanks Tamás.
> Since I use the wrapper, I was thinking there's a case for Maven wrapper
> variants. But I guess this is what containers are all about anyway.
> Delany
>
> On Thu, 7 Oct 2021 at 11:32, Tamás Cservenák <[email protected]> wrote:
>
>> Hi Delany,
>>
>> from Sisu website: "Sisu is a modular JSR330-based container that
>> supports *classpath
>> scanning*, *auto-binding*, and *dynamic auto-wiring*. Sisu uses
>> Google-Guice to perform dependency injection and provide the core JSR330
>> support, but removes the need to write explicit bindings in Guice
>> modules.".
>>
>> Simply, SISU will scan your classpath for components and dynamically pick
>> them up and wire them up.
>>
>> For Guice, you need to _explicitly add_ bindings (as this "dynamism" is a
>> Sisu feature).
>>
>> ServiceLocator is deprecated, leave it out (but same thing stands: is
>> "static").
>>
>> ===
>>
>> More simpler: with Sisu, just throw a component onto classpath, and Sisu
>> will "automagically" pick it up, no code change needed. This is how
>> extensions and other things work in Maven for example (just copy a JAR
>> with
>> components to classpath and they are discovered).
>>
>> Locking implementations like Redisson and Hazelcast are "opt-in", they are
>> not bundled with Maven (to not bloat distro). They work only after you
>> "install" them (provide JARs with their components and all component
>> dependencies to Maven classpath, as explained in the Install step on that
>> page).
>>
>> This remark you quoted is geared more toward "resolver integrators", for
>> those using Resolver into some other project than Maven. If you integrate
>> Resolver, then:
>> - if you use Sisu, you have nothing to do :)
>> - if you use vanilla Guice, then in your integration you have to provide
>> the things you want on classpath and explicitly bind them
>> - if you use ServiceLocator, move away from it (will be soon dropped),
>> simplest is to "roll your own" bootstrap class (that does same as
>> ServiceLocator was doing, statically wiring things up), and again, you
>> should upfront provide whatever you need on classpath and instantiate them
>> using your own "bootstrap" class.
>>
>> If you just want to use it with Maven, nothing to be done for you, just
>> Install it as per page.
>>
>> ===
>>
>> HTH
>> Tamas
>>
>> On Thu, Oct 7, 2021 at 10:07 AM Delany <[email protected]>
>> wrote:
>>
>> > Michael, could you clarify this line pls: "It only works when Sisu DI is
>> > used and not the bundled AetherModule or ServiceLocator (Maven uses Sisu
>> > dependency injection)."
>> >
>> >
>> https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html
>> >
>> > What should I do about this issue?
>> >
>> > Thanks,
>> > Delany
>> >
>> >
>> > On Wed, 6 Oct 2021 at 22:18, Michael Osipov <[email protected]>
>> wrote:
>> >
>> > > Am 2021-10-06 um 21:05 schrieb Francois Marot:
>> > > > Michael, I do not agree. As a user and maintainer of the build
>> chain in
>> > > my
>> > > > company, I think Maven would really benefit from an out of the box
>> > > > solution. I think any user is susceptible to the bug by launching
>> > > multiple
>> > > > Maven instances at the same time on his computer. Bugs then
>> encountered
>> > > are
>> > > > really a bad sign sent to users, and requiring each dev to setup a
>> > > database
>> > > > (even simple) is cumbersome.
>> > >
>> > > I agree with you, but we are developers after all, I can expect people
>> > > to set up something if necessary.
>> > > At the end you need to consider that file based locking has issues, it
>> > > does not work everywhere, it is advisory at best, it protects you only
>> > > from multiprocess access, multithreaded requires an extra layer of
>> > > in-JVM locks. Given that we are all volunteers and the pain for the
>> > > community isn't big enough to contribute something valuable, I won't.
>> > > Especially that Tamás and me invested almost year developing the named
>> > > locks approach with pluggable providers is more than enough to solve
>> any
>> > > type of build setup on any FS and OS.
>> > >
>> > > I'd like to quote Marshall Kirk McKusick: Why write something good if
>> > > you can steal something better? (trade file locks with Redis).
>> > >
>> > > A more lightweight approach would be something like POSIX semaphores
>> > > available everywhere, but Windows. Requires likely native code or JNR
>> > > and time. Out of personal interest I'd peek at it next year.
>> > >
>> > > M
>> > >
>> > > > Le lun. 4 oct. 2021 à 22:13, Michael Osipov <[email protected]> a
>> > > écrit :
>> > > >
>> > > >> Tamás,
>> > > >>
>> > > >> Redis is so easy to install and get going in 5 minutes that I would
>> > > >> rather see your energy go into areas which need more attention.
>> > > >>
>> > > >> M
>> > > >>
>> > > >> Am 2021-10-04 um 22:02 schrieb Tamás Cservenák:
>> > > >>> Hi Bernd,
>> > > >>>
>> > > >>> nothing is wrong with advisory file locking, as long as you don't
>> > store
>> > > >>> local repo on NFS ;)
>> > > >>> Will re-add file locking once I get there, as in my opinion it is
>> the
>> > > >> most
>> > > >>> "lightweight" MP (multi process) solution on a single host.
>> > > >>> Redis and Hazelcast are more for "farms", where several hosts with
>> > many
>> > > >>> processes (and each with many threads) is bashing local repo (that
>> > MAY
>> > > be
>> > > >>> on NFS as well).
>> > > >>>
>> > > >>> Thanks
>> > > >>> Tamas
>> > > >>>
>> > > >>> On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels <
>> > [email protected]
>> > > >
>> > > >>> wrote:
>> > > >>>
>> > > >>>> What’s the problem with adivisory locking, as long as Maven
>> honors
>> > the
>> > > >>>> advice it is the same as it’s a redis lock? (But much less
>> > footprint).
>> > > >> In
>> > > >>>> fact on the same machine it should even work without locking as
>> Long
>> > > as
>> > > >> you
>> > > >>>> use pidfiles?
>> > > >>>>
>> > > >>>> Gruss
>> > > >>>> Bernd
>> > > >>>>
>> > > >>>>
>> > > >>>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> To unsubscribe, e-mail: [email protected]
>> > > >> For additional commands, e-mail: [email protected]
>> > > >>
>> > > >>
>> > > >
>> > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [email protected]
>> > > For additional commands, e-mail: [email protected]
>> > >
>> > >
>> >
>>
>
