Well, I think it is rather ironic, because the original design specifically went for multiple executables that could be able to distribute the load on different networked servers. Wasn't it one of the reasons of the redesign from jabberd14?
I realize the question is whether this use-case is efficient, and whether your bottleneck is socket-IPC or CPU load. You'll be switching from working-around-cpu-bound hypothesis to work-around-io-bound. Do you know if anyone really uses jabberd2 in a distributed manner? I just wanted to point out that this went against the history of jabberd2. It's not a technical issue :) Otherwise, I think it is indeed worthwhile direction. In fact, it would be a big enough evolution to warrant renaming the project, as you previously wanted, no? :) Regards, jean On 6/5/08, Tomasz Sterna <[EMAIL PROTECTED]> wrote: > We were talking with Ono today about merging all jabberd 2 sub > applications (router, c2s, s2s, sm) into one binary, with multiple > threads running each components. > That would mainly reduce maintenance and deployment effort. You would > run one process instead of several ones. > And wouldn't keep one from running each component in separate process - > just run only one thread+component in each instance. > > With such design there are some performance optimisations possible in > router, that could just pass pointers to data instead of pushing the > data through TCP sockets. > There are some problems with current single-thread design of jabberd, > but we think they are easily solvable. Ex. static buffers with thread > local-storage. > > What do you think about this idea? > Is it worth pursuing? Or not worth the effort? > > > -- > /\_./o__ Tomasz Sterna > (/^/(_^^' http://www.xiaoka.com/ > ._.(_.)_ im:[EMAIL PROTECTED] > > > > -- > To unsubscribe send a mail to [EMAIL PROTECTED] > >
