0.2.7: TCP server no longer works on non-Linux OS'es

244 προβολές
Παράβλεψη και μετάβαση στο πρώτο μη αναγνωσμένο μήνυμα

dante briones

μη αναγνωσμένη,
8 Ιαν 2015, 6:05:01 μ.μ.8/1/15
ως rieman...@googlegroups.com
Hey folks,

I just tried out upgrading to 0.2.7 and got the log output below. I remembered a Netty upgrade in the change log and so took a look at the Netty web site and found:


So it seems that any classes that start with "EPoll" only work on Linux. Unfortunately, neither our production servers (SmartOS) nor my development machine (OS X) are Linux, so I'm a bit dead in the water here.

From the page above, it looks like maybe we could do an even swap of the EPoll* classes for equivalent NIO ones? What do you think about using the NIO versions as a default and allowing use of the EPoll ones as a Linux-specific performance optimization available as a system property?

Thanks,

Dante


```
14:51:45 powerhaus riemann-0.2.7 $ bin/riemann
log4j:WARN No appenders could be found for logger (io.netty.util.internal.logging.InternalLoggerFactory).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
INFO [2015-01-08 14:51:55,949] main - riemann.bin - PID 15728
ERROR [2015-01-08 14:51:55,994] main - riemann.bin - Couldn't start
java.util.concurrent.ExecutionException: java.lang.ExceptionInInitializerError
 at java.util.concurrent.FutureTask.report(FutureTask.java:122)
 at java.util.concurrent.FutureTask.get(FutureTask.java:188)
 at clojure.core$deref_future.invoke(core.clj:2180)
 at clojure.core$future_call$reify__6320.deref(core.clj:6420)
 at clojure.core$deref.invoke(core.clj:2200)
 at clojure.core$map$fn__4245.invoke(core.clj:2559)
 at clojure.lang.LazySeq.sval(LazySeq.java:40)
 at clojure.lang.LazySeq.seq(LazySeq.java:56)
 at clojure.lang.RT.seq(RT.java:484)
 at clojure.core$seq.invoke(core.clj:133)
 at clojure.core$dorun.invoke(core.clj:2855)
 at riemann.core$transition_BANG_.invoke(core.clj:156)
 at clojure.lang.Atom.swap(Atom.java:51)
 at clojure.core$swap_BANG_.invoke(core.clj:2233)
 at riemann.config$apply_BANG_.invoke(config.clj:293)
 at riemann.bin$_main.invoke(bin.clj:69)
 at clojure.lang.AFn.applyToHelper(AFn.java:156)
 at clojure.lang.AFn.applyTo(AFn.java:144)
 at riemann.bin.main(Unknown Source)
Caused by: java.lang.ExceptionInInitializerError
 at io.netty.channel.epoll.EpollEventLoop.<init>(EpollEventLoop.java:70)
 at io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:71)
 at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64)
 at io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49)
 at io.netty.channel.epoll.EpollEventLoopGroup.<init>(EpollEventLoopGroup.java:56)
 at io.netty.channel.epoll.EpollEventLoopGroup.<init>(EpollEventLoopGroup.java:48)
 at io.netty.channel.epoll.EpollEventLoopGroup.<init>(EpollEventLoopGroup.java:41)
 at io.netty.channel.epoll.EpollEventLoopGroup.<init>(EpollEventLoopGroup.java:34)
 at riemann.transport.tcp.TCPServer.start_BANG_(tcp.clj:119)
 at riemann.service$fn__1886$G__1880__1888.invoke(service.clj:20)
 at riemann.service$fn__1886$G__1879__1891.invoke(service.clj:20)
 at clojure.core$pmap$fn__6328$fn__6329.invoke(core.clj:6466)
 at clojure.core$binding_conveyor_fn$fn__4145.invoke(core.clj:1910)
 at clojure.lang.AFn.call(AFn.java:18)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Only supported on Linux
 at io.netty.channel.epoll.Native.<clinit>(Native.java:44)
 ... 18 more
```

Kyle Kingsbury

μη αναγνωσμένη,
8 Ιαν 2015, 6:24:53 μ.μ.8/1/15
ως rieman...@googlegroups.com
On 01/08/2015 03:05 PM, dante briones wrote:
> Hey folks,
>
> I just tried out upgrading to 0.2.7 and got the log output below. I remembered a
> Netty upgrade in the change log and so took a look at the Netty web site and found:
>
> http://netty.io/wiki/native-transports.html
>
> So it seems that any classes that start with "EPoll" only work on Linux.
> Unfortunately, neither our production servers (SmartOS) nor my development
> machine (OS X) are Linux, so I'm a bit dead in the water here.
>
> From the page above, it looks like maybe we could do an even swap of the EPoll*
> classes for equivalent NIO ones? What do you think about using the NIO versions
> as a default and allowing use of the EPoll ones as a Linux-specific performance
> optimization available as a system property?

Whoops, serves me right for not reviewing the netty 4 patches carefully enough.
Somehow didn't connect the dots between "Epoll" and "Linux-only-feature", haha.

That is absolutely the right call, and should be a pretty straightforward patch
to transport/tcp.clj and maybe transport/udp.clj. We should be able to do
platform detection at runtime and swap in the right classes automatically.

I'm pretty backed up at the moment but would like to release an 0.2.8 with this
change as soon as possible. If you want to shoot me a PR for this it'd be a
terrific help.

--Kyle

dante briones

μη αναγνωσμένη,
8 Ιαν 2015, 6:50:14 μ.μ.8/1/15
ως rieman...@googlegroups.com
I'm pretty backed up at the moment but would like to release an 0.2.8 with this 
change as soon as possible. If you want to shoot me a PR for this it'd be a 
terrific help. 

Yup, PR here (which you've already seen :) )

I'll looks into the platform detection as I mentioned in the PR.

dante briones

μη αναγνωσμένη,
9 Ιαν 2015, 12:49:03 μ.μ.9/1/15
ως rieman...@googlegroups.com

I'll looks into the platform detection as I mentioned in the PR.

Done. The TCP code now checks the current operating system and only uses the Epoll classes if it's running on Linux. It uses the NIO classes for all other OS'es. No config required! 

--Dante
Απάντηση σε όλους
Απάντηση στον συντάκτη
Προώθηση
0 νέα μηνύματα