These are chat archives for atomix/atomix

6th
Sep 2018
Jordan Halterman
@kuujo
Sep 06 2018 01:12 UTC
Distributed Lock Demo
Distributed lock demo using the cli ⬆️
Jordan Halterman
@kuujo
Sep 06 2018 16:35 UTC
@lburgazzoli that doesn’t seem like a good way to solve a bug. Can you paste a stack trace?
is that code publicly visible?
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 16:36 UTC
@kuujo yes it is
I've also raised an issue to have a custom atomix registry that leverages i.e. spring to discover things
it looks like the same class is loaded by different classloaders
at the moment my code relies on a custom atomix build that allow to inject a custom registry
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 16:45 UTC
but it can easily be reverted to use the class path scanning registry
Maxim Manco
@mmanco
Sep 06 2018 17:26 UTC

Hi guys, I've been playing with Atomix for the past month and finally came with a locally working solution (direct and through docker) that suites our needs. the problem start when I try to deploy the service under kubernetes.
I am seeing bunch of io.netty.handler.codec.DecoderException:

io.netty.handler.codec.DecoderException: java.net.UnknownHostException: addr is of illegal length
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:459) ~[netty-codec-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:392) ~[netty-codec-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:359) ~[netty-codec-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:342) ~[netty-codec-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245) [netty-transport-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231) [netty-transport-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224) [netty-transport-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1429) [netty-transport-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245) [netty-transport-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231) [netty-transport-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:947) [netty-transport-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:822) [netty-transport-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163) [netty-common-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404) [netty-common-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:322) [netty-transport-native-epoll-4.1.27.Final-linux-x86_64.jar!/:4.1.27.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884) [netty-common-4.1.27.Final.jar!/:4.1.27.Final]
        at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
Caused by: java.net.UnknownHostException: addr is of illegal length
        at java.net.InetAddress.getByAddress(InetAddress.java:1042) ~[na:1.8.0_121]
        at java.net.InetAddress.getByAddress(InetAddress.java:1439) ~[na:1.8.0_121]
        at io.atomix.cluster.messaging.impl.MessageDecoder.decode(MessageDecoder.java:87) ~[atomix-cluster-3.0.3.jar!/:na]
        at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489) ~[netty-codec-4.1.27.Final.jar!/:4.1.27.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428) ~[netty-codec-4.1.27.Final.jar!/:4.1.27.Final]
        ... 16 common frames omitted

@kuujo Finally found the root cause for this issue. Apparently, we have an internal k8s extension which does probing.
for some reason it probes every single port which is exposed by the container causing the decoder to receive a message with totally wrong payload.
Everything works like a charm after disabling this extension. Sorry for the false alarm!

Jordan Halterman
@kuujo
Sep 06 2018 20:40 UTC
@lburgazzoli the class path scanner is only instantiated once using a single class loader per Atomix instance… unless you’re running the agent in which case a second scanner is created for REST API resources
@mmanco good find! Makes sense
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 20:42 UTC
@kuujo what I mean is that the implementation may use different classloader than the one atomix sets, that's the only reason that explains the issue
Jordan Halterman
@kuujo
Sep 06 2018 20:42 UTC
definitely seems like a class loader issue though
yeah
so you should provide a class loader to Atomix
probably the only way to avoid class loader hell
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 20:43 UTC
maybe is is better to provide a way to provide a custom atomix registry
(as the issue I've opened)
so as example you can register namedtypes in spring
Jordan Halterman
@kuujo
Sep 06 2018 20:44 UTC
sure I think that’s fine
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 20:44 UTC
and get them looked up by the registry
Jordan Halterman
@kuujo
Sep 06 2018 20:44 UTC
there’s already an interface
all we have to do is make the implementation configurable
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 20:44 UTC
yes I have an example in my branch
which uses spring application context for discovery
I can provide a pr, the only thing I need to know is where you want to let user register a custom registry
Jordan Halterman
@kuujo
Sep 06 2018 20:46 UTC
that’s what I’m thinking about
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 20:46 UTC
as today I have something like Atomix.builder(registry)
Jordan Halterman
@kuujo
Sep 06 2018 20:46 UTC
that’s probably fine
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 20:46 UTC
but I guess you also need aother build methods to accept a registry
of course I can duplicate every build method :)
Jordan Halterman
@kuujo
Sep 06 2018 20:47 UTC
I think we may not need overloaded methods with the ClassLoader if a registry is provided
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 20:47 UTC
ok
Jordan Halterman
@kuujo
Sep 06 2018 20:48 UTC
pretty sure that’s all it’s used for
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 20:48 UTC
let me work on a pr
Jordan Halterman
@kuujo
Sep 06 2018 20:48 UTC
:+1:
Luca Burgazzoli
@lburgazzoli
Sep 06 2018 20:48 UTC
btw do you use atomix in osgi ?
which container ? karaf ? or a custom one
Jordan Halterman
@kuujo
Sep 06 2018 20:49 UTC
Karaf