감사합니다.
Netty4 에 대해 이야기해볼까요
좋습니다.
다음과 같은 것들 ..음 ChannelHandlers 가 소수의 이벤트를 발생시키는것과 같은것 뿐 만 아니라, 모듈화 방식 변경에 대해 파고들었는데요...
예.. 우리는 몇가지 이슈를 가지고있었어요..무거운 이벤트 생성 GC-presure 같은 .. 그런것들을 바로잡을 시간이라 생각했습니다.
Vert.x 말고 Netty 4 기반의 다른 프로젝트에 대해 인지하시는지? 개인적으로 , 좀더 실세계 예제를 보고 싶은데요..
몇가지 Netty 4로 포팅하려는 프로젝트들은 있어요 뭐.. 그들 대부분은 아직 시작이지만요..
이런 질문을 하게 만드는 이유는 Netty 4 가 매우 큰 진보를 하고있다는게 분명히 다가오는데에 있는데요 (new Buffer handling, ChannelFuture-s, easier resource management, leak detection etc.) 근데 마이그레이션은 꽤 까다롭다고 생각되는데요.
오케이, 몇가지 구체적으로 말해보자면, Vert.x 는 좀 도전적이죠. Vert.x 를 작업하는 팀의 일부분인게 놀라운건 아니지만.. 다음 프로젝트는 제가 알기론 HornetQ 의 Netty 4 적용일거에요.
좀 더 작은 프로젝트들도 몇개있긴해요. 매력적이지만 좀 느리게 진행되는데, 무거운 API 들과 양질의 문서화때문일거에요. 우리의 약한부분이기도 한데 나의 책과 함께 좀 더 나아지게 할것입니다.
전반적으로 오래된 유저들 (새로운 컨셉에 적응해야할) 보다는 새로 진입하는분들이 적응하긴 쉬울꺼에요, 예를들어 Netty 3 유저들은 왜 버퍼들이 이제 pooled 되었는지도 이해해야하고 그들을 릴리즈하는게 누구 책임인지도 이해해야하죠.
이런 변경은 좋은방향으로 나아갈겁니다. 우리의 벤치마크에 따르면 Vert.x 의 pooled 버퍼는 un-pooled 에 비해 10% 스피드업이라는 결과를 보여주고 있어요.
전에 리소스 핸들링에 대해서 다시 생각하고있다는걸 언급했었는데요, 버퍼 리소스를 해제시키는게 누구 책임인가요? pool 에 의해 다 해결되나요?
아니요. 기본적으로 인바운드 트래픽에 대해서 네티의 transport 는 pool 바깥에서 버퍼를 얻습니다. 그리고나서 파이프라인을 통해 버퍼를 통과시키고 , ChannelInboundHandler 는 버퍼를 받아요. 파이프라인의 마지막 핸들러는 그것을 해제시킬 필요가 있습니다.
새로운 메모리릭 감지기는 버퍼가 제대로 해제가 안되었을경우 잡을수 있나요?
우리의 엔코더와 디코더는 자동적으로 버퍼를 해제합니다. 우리는 SimpleChannelInboundHandler 를 제공하고 있는데 이것은 모든 버퍼를 자동 해제합니다. 대조적으로 ChannelInboundHandlerAdapter 그렇지 않아요. 대부분의 경우에서는 전자를 사용할수있을겁니다. ByteBuf 를 직접 다룰경우나 동일한 버퍼를 채널에 돌려주면서 쓰는곳은 좀 예외겠지만요. (에코서버나 프록시같은). 아웃바운드(즉 write) 경우는 버퍼는 채널에 쓰기가 완료되면서 해제됩니다. 메모리릭 감지기는 이런것들을 감지하고 경고를 로깅할것입니다.
알겠습니다. 좀 더 가벼운 주제로 바꿔보겠습니다. 만약 HTTP server 를 만들필요가 있을때 기반으로 Netty4 나 Vert.x 중 무엇이 좋을까요? 둘다 좋을거 같긴한데요.
글쎄요. 네티는 좀더 로우레벨이죠. ( 역주 : 개인적으로는 Vert.x 를 로우레벨로 쓰는것은 어떨지 궁금하다, 즉 거의 모든 경우에 있어서 Vert.x 를 사용하고 싶다는 ...)
sockJs 가 Netty4 를 hits 한다고 한다면 , Vert.x 구현체를 사용해야하나요?
바라보는곳이 어딘지에 따라 달라지겠지요. Vert.x 는 네티에 비해 좀더 많은것을 제공하고있어요. 만약 여러가지 애드온이나 라이브러리가 필요하지 않다면 , 그냥 네티가 좋을수도있구요, Vert.x 는 정말 다양한 API 를 제공하고있어요, 또 만약 polyglot 으로 가고 싶다면 Vert.x 죠.
Vert.x 2.0 에서는 모듈 시스템이 많이 발전된것처럼 보입니다. 이 새로운 구조에 대해서 말해주시겠습니까? maven repos 에 모듈들을 등록해놓고 가져다 사용한다는것이 참 매력적으로 보입니다.
ok~ 우리는 Vert.x 의 많은 부분을 모듈을 사용하여 플러거블하게 바꾸었습니다. 좀 더 가볍게되었지요. 전에는 다양한 언어의 API 들이 무겁게 엮여있었어요. 지금은 모든것이 모듈입니다. 그것은 엔드유저가 사용하기 쉽게 만들었어요. 재사용 컴포넌트를 만드는것도 쉽구요. 모듈에 대한 전체 아이디어는 Node.js 와 비슷합니다. 즉 그들의 모듈을 쉽게 등록하게하는것이죠.
이 모든것은 꽤 환영할만한 변경인거 같습니다.
곧 Scala 나 Clojure 를 지원하는것을 보고싶네요. php 를 시작한 멤버도 있습니다.
언어 모듈은 엔드유저 API 를 래핑하는건가요? 아니면 좀 더 아랫단에 가깝게 접근하나요?
언어모듈은 그냥 java API 를 둘러싼 래퍼입니다.
...and as for custom modules, are those polyglot, too?
For custom modules you can depend on whatever other module you want too... so yes. The runnable modules communicate over the EventBus (JSON) so you can use a module and not care about in which language it was written.
I found the polyglot story interesting but to be honest, I have some reservations. In my experience, maintaining mixed projects (mixed in terms of languages) can be painful. Especially when the need of passing native data types arises
I think it is a matter of taste. I would, for example, only choose one language and stick with it when working on a project but if you split your project into different modules, you can mix things easily. For example, one team could work on a db driver and write it in JavaScript as all of them are js devs, another team would work on the core backend but use the db driver via theEventBus (JSON) and even not knowing that it was written in JavaScript. So mainly the polyglot thingy gives everyone freedom and still allows easy reuse.
Yeah - I certainly can see different JVM langs interoperating on a service level (lots of companies are building on the JVM in this fashion i.e. Twitter, Netflix etc.) my comment was more about working within a single project.
I agree - mixed languages in one "module/service" can cause problems in term of maintenance. Personally I would choose one lang and stick with it per "service/module".
The new vert.x website characterizes the EventBus as "actor-like". Where do you think the difference is?
Well, Vert.x gives you all in one platform, with actor based system you still need to stick in your own HTTP server whatever like Spray does. So I see Vert.x more like a complete platform which allows to write async network code, potentially using multiple languages.
I saw a few community projects popping up on the mailing list
Yep. We got a few now...
Can you name a few 3rd party extensions that you are particularly fond of?
The one I really find interesting, which is still in active development, is a module which provides async mysql/postgresql access without using JDBC at all. Db access is still a big problem in the async world.
Yeah, totally. That's a big pain point...
In fact, I just started to port the original code to Netty4 to make sure it is run on the same EventLoop as Vert.x.
The other interesting project I'm waiting for is an async DNS codec. We actually want to make use of this DNS solution in a vert.x module.
I also saw some activities around RxJava support. Are you planning any official module for that?
We are working on it ;)
While we are at modules, I remember seeing a web framework/middleware on top of Vert.x, too
yeah that's called Yoke.
Do you see Vert.x as an end user library or folks should see it as higher abstraction than Netty but lower than say Play?
Basically what we want to offer with Vert.x is an easy way to write network services which can scale and everything on top should go in modules. We hope to make it easy to implement extra features as modules and register them in our module registry.
I was quite surprised to see that vert.x embed got some extra support in 2.0. When we talked about Vert.x a while back, the future of the embedding feature was less clear...
haha... I think one of the really hot things in this area is the .js support
Do you guys plan to have anything special for Nashorn?
We have licensing issues with Nashorn [Nashorn is under GPL2] which is unfortunate.
But what quite interesting in JavaScript land is a node.js module which allows you to write node.js apps on top of Vert.x. It's still work-in-progress but it will provide a relatively easy migration path. Vert.x really out-performs node.js in many ways.
My final questions are about the whole event-driven space which seems to be booming these days.
What do you think about Reactor?
Reactor uses Netty [for their TCPServer/Client implementation], so I'm in contact with them. I think this space is indeed really hot at the moment and we will surely see a lot of traction in the future. The problem is that there are still a lot of legacy libraries around which slow things down.
Jonas Bonér from Typesafe was pushing for a shared vocabulary. Any thoughts on this initiative?
Yeah the manifesto ... To be honest, I think it's nothing new.. In fact, many frameworks do exactly what is written there. For example, all the event related attributes he mentions were also implemented in Netty 3. Vert.x also fits into this paradigm quite well.
What other collaborations can you imagine between these various projects (Vert.x, RxJava, Akka, Netty, Finagle, Reactor etc. etc.)?
Finagle is built on top of Netty - so obviously there is collaboration there already. Same for Play[although Play may switch to akka-io at some point but we'll see]. As for Reactor, I helped them with their Netty-based TCP implementation.
Well, that was it. Thanks for your time!
Thank you.
The_Netty_Project_3.1_User_Guide.doc
