Tomasz Sterna wrote:
Dnia 2008-06-05, czw o godzinie 11:18 -0400, Christopher Zorn pisze:
> And wouldn't keep one from running each component in
separate
> process - just run only one thread+component in each
instance.
I believe this would be a mistake. The original design is to scale
across multiple computers. I think it is an easier and better way to
scale. Just ask the ejabberd guys.
I do not think I would continue to use jabberd2 if this decision was
made. I use it for the sole reason to have the components spread
across computers. Connecting components to jabberd2 works better than
ejabberd too, the router is nice.
Now I realize, that I skimmed on current model compatibility a bit too
much.
So, let me explain the idea again.
Merging all components into one 'jabberd' binary, allows easier
maintainability and removes code duplication.
It does not bring any "real" performance improvements. We're I/O-bound
anyway...
Nothing stops deployment from running each component separately:
/usr/bin/jabberd -c /etc/jabber/router.xml
/usr/bin/jabberd -c /etc/jabber/sm.xml
/usr/bin/jabberd -c /etc/jabber/c2s.xml
/usr/bin/jabberd -c /etc/jabber/s2s.xml
Where each .xml config file contains only <router>, <sm> etc. sections,
thus launching only one thread inside each process for only one
component.
But for small deployments
/usr/bin/jabberd -c /etc/jabberd/full.xml
would be enough to run router, c2s, s2s and several sm instances (each
with own <sm> section in full.xml) in one multithreaded process.
And I also do not intend to remove the TCP way of connecting components.
Just add second way of "connecting" a component running in another
thread of the router, by direct wio->rio pointers passing.
This would allow greater flexibility for both small, single machine
deployments with one, easily managable process, and large multi machine
deployments with components distributed over many machines.
I wouldn't multi-thread the binary. In my (pretty extensive)
experience, that's a way to introduce many subtle bugs.
I think it would be fine to have a single binary, that either based on a
command line switch, or by being executed with a different name,
performs just one of the tasks (like /bin/gzip vs. /bin/gunzip).
You could also do something like postfix, where you only start the
single master process, and it inspects the config files and starts the
appropriate child processes.
Eric.
--
To unsubscribe send a mail to [EMAIL PROTECTED]
