w**z
发帖数: 8232 | 1 http://www.javaworld.com/article/2104441/enterprise-application
"JavaScript everywhere, and everything ported to JavaScript" -- it's either
a running joke in IT these days or a stone-cold truth. Evidence is tending
toward the latter, what with Node.js becoming a jack-of-all-trades framework
for many workloads and environments.
With Nodyn, Node.js gains yet another place it can run: the Java Virtual
Machine.
Nodyn, a project sponsored by Red Hat via its Project:Odd team, works by
leveraging two other projects: the DynJS project, which provides the actual
JavaScript runtime (ECMAScript, actually) for the JVM, and the Vert.x
application platform/event bus system.
But the main motive for allowing Node.js apps run on the JVM isn't the mere
novelty of doing so; it's about allowing Node.js apps to work directly with
existing Java apps. Consequently, the Nodyn project is also part of the
JBoss ecosystem for the sake of further integration with the rest of the
Java application world, as well as apps from any other language currently
running on the JVM (such as, Clojure).
Because of the way Nodyn is implemented, it isn't a direct port of the Node.
js code. Instead, it replicates the functionality of Node.js's APIs. Not
everything works yet -- the wiki page devoted to tracking Nodyn
compatibility with Node.js shows how things like the VM API (itself unstable
in Node.js) and TLS/SSL haven't been implemented yet. Anyone expecting drop
-in compatibility for Node.js apps at this stage is going to be let down;
for now the project is best approached as a future direction for Node.js and
Java to move closer together, not as an actual production solution.
Nodyn is far from the only way to have Node.js talk to other platforms. One
solution native to Node itself is node-ffi -- short for "Foreign Function
Interface" -- which allows Node.js to create bindings with dynamic libraries
without needing any C++ code on the part of the Node.js programmer. It isn'
t clear yet how node-ffi's performance will stack up against Nodyn in the
long run, although Nodyn seems like it's aiming to be the far more complete,
robust solution of the two, thanks to such features as the clustering
capabilities inherent in Vert.x. | z****e
发帖数: 54598 | 2 这就是vert.x一直在做的那个兼容node.js的模块
vert.x里面有好几个很有趣的东西，比如rxjava
netflix做的，用来实现异步处理，当然还有clojure这些 | z****e
发帖数: 54598 | 3 Nodyn用了red hat自产的一个js引擎
我对red hat有信心，至少比那个做firefox的mozilla要强不少
vert.x的缺省js引擎是mozilla做的犀牛 | d*******r
发帖数: 3299 | 4 http://nodyn.io/compatibility/
Cluster
Node.js reference http://nodejs.org/api/cluster.html
Clustering is handled for now through vert.x builtin clustering, which
itself uses hazelcast for the implementation. Vert.x does not yet expose
clustering data or an API.
以前看 vert.x 的时候看到过这个 dependence: Hazelcast
http://www.hazelcast.com/
难道就是自带 cluster 模式的 memory DB ? 那 Redis(cluster) or memcached 都不
用搞了!? | d*******r
发帖数: 3299 | 5 有人用过 Hazelcast 吗? 看着很适合做 real time system 的样子
http://www.infoq.com/cn/news/2014/02/hazelcast-mapreduce-api
Christoph：Hazelcast当前在金融领域发展迅猛，用于低延迟交易应用、风险、金融交
易和其它类似的应用。大型电信公司、网络设备制造商和云提供商也在用它。我们还看
到，它开始应用在诸如互联网和移动支付、游戏和赌博、旅行和餐饮以及电子商务等领
域。
http://hazelcast.org/use-cases/in-memory-nosql/
Going Off Heap
Hazelcast focuses on latency and makes it easier to cache/share/operate TB’
s of data in-memory. Storing terabytes of data in-memory is not a problem
but avoiding Java Garbage Collection (GC) to achieve predictable ... ...
Elastic Memory is Hazelcast with off-heap memory storage to avoid GC pauses.
Even if you have terabytes of cache in-memory with lots of updates, GC will
have almost no effect; resulting in more predictable latency and throughput.
Elastic Memory implementation uses NIO DirectByteBuffers and doesn’t
require any defragmentation. Here is how things work: ... ... | m******t
发帖数: 635 | 6 这个东东听起来不错啊，有空琢磨下
【在 d*******r 的大作中提到】
: 有人用过 Hazelcast 吗? 看着很适合做 real time system 的样子
: http://www.infoq.com/cn/news/2014/02/hazelcast-mapreduce-api
: Christoph：Hazelcast当前在金融领域发展迅猛，用于低延迟交易应用、风险、金融交
: 易和其它类似的应用。大型电信公司、网络设备制造商和云提供商也在用它。我们还看
: 到，它开始应用在诸如互联网和移动支付、游戏和赌博、旅行和餐饮以及电子商务等领
: 域。
: http://hazelcast.org/use-cases/in-memory-nosql/
: Going Off Heap
: Hazelcast focuses on latency and makes it easier to cache/share/operate TB’
: s of data in-memory. Storing terabytes of data in-memory is not a problem
|
|
