java does not waste any system memory. It manages its memory fairly good compared to other OO languages.
Does ejabbered run in an application server?
wouldn’'t it be a really nice thing to combine the best of both projects?[/i]
It’‘s usually very hard to convince one of the authors to stop working on its project. And yes it would be nice, so I wonder why no one did create a new project which combines the best of both projects. It’'s only a little bit of work to do …
Ejabberd uses the very obscure Erlang platform. One thing that’‘s similar to Java about Erlang is that it uses a virtual machine. However, the Java virtual machines are much more advanced (as one might expect given Java’‘s popularity). So, I really doubt that Erlang has better memory management than Java. In fact, it’‘s quite easy to configure Wildfire to use as much or little memory as you’'d like. One community member runs Wildfire with something like 64 MB total RAM(!).
Anyway, I agree that ejabberd has some interesting features and we enjoy cooperating with them as part of the open XMPP protocol process. However, there’'s really no way to share code given our vastly different architectures.
i am no expert, i just repeated, what i read before.
and i tested both wildfire and ejabberd.
i really noticed much less memory consumption with using ejabberd.
and i thougth that erlang is THE swiss army knife for fault tolerant high capacity communication applications.
from what i tried myself and what i read i just expect, that wildfire is not adequate for sites with really a lot of users…?!?
i saw, that you are working on a clustering system, but this looks a bit like “okay - our car needs 40 litres per 100km; now we are developing a nice gasoline trailer”
i really noticed much less memory consumption with
using ejabberd.
Anything is possible. But, this would be due to Wildfire and not Java itself.
i saw, that you are working on a clustering system,
but this looks a bit like "okay - our car needs 40
litres per 100km; now we are developing a nice
gasoline trailer"
Heh, interesting analogy. There’'s actually two parts to the scalability work:
Connection managers (what you mention). This will allow multiple servers to take on the burden of handling client connections.
Switching to the NIO library. Instead of using a single thread for each connection, NIO handles all connections with a very small number of threads. This allow for much greater scalability.
Part 1 is done and stable for Wildfire 3.0. There has been some good work done on part 2, but it will be experimental for several months while in-depth testing is done.
He also tested ejabberd on it (he just said me in an IM message) and he tells that it worked very responsive. Of course you shouldn’'t try to serve 100,000 concurrent users with such a device
Anyway, I agree that ejabberd has some interesting
features and we enjoy cooperating with them as part
of the open XMPP protocol process. However, there’'s
really no way to share code given our vastly
different architectures.
On the other hand, there is much cooperation possible in the non-code area (cfr. Jabberpedia and marketing a la LCS).
(as one might expect given Java’'s popularity). So,
I really doubt
that Erlang has better memory management than
Java.
Erlang has a better memory management than Java because it has to fullfill one more constraint: Soft real time. This means that the VM cannot block the execution flow and has to do some micro garbage collections. In Java, you often have to face one or two second lag when a heavy garbage collection is triggered. Erlang also offer the opportunity to tune the memory management in nearly every aspect. You can really fine tune the memory management of the system very deeply.
I definitely don’‘t want to start a Java vs. Erlang discussion. Modern Java VM’‘s generally all support soft-real time garbage collectors as well. For example, JRockit (BEA) has a new garbage collector that generally never pauses more than a few milliseconds. IBM and Sun have much the same in their latest VM’'s as well. Of course, you pay for soft-real time with lower total through-put. The cool thing is the ability to tune for different use cases which both Java and Erlang offer. There really is a lot of power by going with a virtual machine approach.
Anyway, I’‘m locking this thread now as it’'s getting off-topic.