3 ms·

I've often thought of doing a high volume messaging project with Node.js but I seem to be addicted to jBoss Netty.

hello_moto 15y ago
Do you mind to explain a little bit more on why you are addicted to JBoss Netty? I don't mean to hi-jack Node thread but I'm curious since I use Java day-to-day and would love to hear more about non-web-app framework type of activities in Java.
- badmash69 15y ago
  We were using TIBCO with JMS API to process data as a part of batch job. The batch job would send a message to a JMS Queue; the listener would then process the message and insert it into a db. Replace the system with Netty based RPC servers. Now the batch job makes async RPC calls to the Netty RPC server. The overall system is now several times faster. And the error handling is now much more elegant . Not to mention that not having to deal with our enterprise infrastructure(Tibco team) guys is an added bonus.
  - hello_moto 15y ago
    JMS can do async call as well is it not? Is using JMS make programming more clumsy? listener vs pure async. What about the RPC stuff, do you have to write a custom serialization ?
cygwin98 15y ago
Depends on the traffic you need to work with. I've kept an eye on Node.js for some time. So far, among the failures involved with Node.js are Plurk and SyncPad. Plurk switched to JBoss Netty, while SyncPad used Erlang instead. Though that was almost a year ago, things may have improved. Not to bad-mouth Node.js here. Just to give some counter examples to anybody who wants to try Node.js in production.
- tszming 15y ago
  Plurk? Seems they changed from Netty to Node JS, not vice versa?
  - simonw 15y ago
    They switched back to Netty again: http://amix.dk/blog/post/19577 http://amix.dk/blog/post/19577
    - tszming 15y ago
      Thanks for the link. It seems running multiple instance of node.js and use a more updated version would helps (maybe). Anyway, I always think that lack of threading support is definitely a feature instead of incompetency. Threading is hard and average developers should avoid it. (Unless you are doing scientific computing). If you need to scale, eventually you will need multiple servers anyway.

Do you mind to explain a little bit more on why you are addicted to JBoss Netty? I don't mean to hi-jack Node thread but I'm curious since I use Java day-to-day and would love to hear more about non-web-app framework type of activities in Java.

badmash69 15y ago
We were using TIBCO with JMS API to process data as a part of batch job. The batch job would send a message to a JMS Queue; the listener would then process the message and insert it into a db. Replace the system with Netty based RPC servers. Now the batch job makes async RPC calls to the Netty RPC server. The overall system is now several times faster. And the error handling is now much more elegant . Not to mention that not having to deal with our enterprise infrastructure(Tibco team) guys is an added bonus.
- hello_moto 15y ago
  JMS can do async call as well is it not? Is using JMS make programming more clumsy? listener vs pure async. What about the RPC stuff, do you have to write a custom serialization ?

cygwin98 15y ago

Depends on the traffic you need to work with. I've kept an eye on Node.js for some time. So far, among the failures involved with Node.js are Plurk and SyncPad. Plurk switched to JBoss Netty, while SyncPad used Erlang instead. Though that was almost a year ago, things may have improved. Not to bad-mouth Node.js here. Just to give some counter examples to anybody who wants to try Node.js in production.

tszming 15y ago
Plurk? Seems they changed from Netty to Node JS, not vice versa?
- simonw 15y ago
  They switched back to Netty again: http://amix.dk/blog/post/19577 http://amix.dk/blog/post/19577
  - tszming 15y ago
    Thanks for the link. It seems running multiple instance of node.js and use a more updated version would helps (maybe). Anyway, I always think that lack of threading support is definitely a feature instead of incompetency. Threading is hard and average developers should avoid it. (Unless you are doing scientific computing). If you need to scale, eventually you will need multiple servers anyway.