[JDEV] Sparse considerations about server status

[jabber at msg.net]

> Sorry if I begin with something off-topic. I've just read this 
> message on the list:
> 
> "jabber at msg.net" wrote:

For the record:

I have no association with Jabber.com or the Jabber Commercial Server (JCS).
I do have some communication with them regarding a potential deployment --
I've tried to arrange a demo license, but my budget won't cover a license
this year, and my applications are too small scale (the largest is around
500-1500 concurrent users, under 8K total accounts) to be of interest.


> I was a little bit shocked. Reading these considerations anyone
> would argue that 'serious' guys should buy the commercial server...

That is my argument. If you are _serious_ about a large scale deployment,
about using Jabber as an enterprise IM solution, then JCS must be considered
as an option.  One service I provide to my clients is assistance in making
these types of decisions. 

For some clients, the non-monetary 'cost' of building business processes on
an 'Open Source' product outweigh the price tag of deploying a 'commercial'
product.  Some of these clients will deploy JCS, some will deploy Lotus
Sametime, and some (against my advice) may deploy the Microsoft Messenger
intranet service (included in the next Exchange server package).

For many applications, the open source jabber server is a viable option,
and I do have several small scale (one or two server machines) deployments
of the open source server.


> This is unfortunate as it was like reading on Apache mailing list 
> someone implying that you should buy a Netscape Enterprise Server 
> license to get rid of Apache's flaws.

Then you got the wrong impression (BTW, I was involved with the NCSA server
long before the release of the set of patches later known as 'Apache').  I
suggest that it is more akin to reading, just a few years ago, on an Apache
mailing list that you should consider purchasing a Stronghold license if
you want a polished implementation of SSL.

Back when the web (meaning HTTP services) was young, there was a period of
time when Netscape's server had a clear advantage, with the first stable
implementation of preforking, and other performance and stability
improvements,  At that time, when I was asked to recommend a web server for
'serious' users, I would have been doing a disservice to have recommended
NCSA/Apache over Netscape, except where the sole consideration was the
initial price tag, without any consideration for total cost of ownership.

I manage a number of Apache servers, but I also work with sites that have
large deployments of Netscape Enterprise Server. I see no conflict in that.


> I thought this mailing list  was to deal with the OpenSource server.
> Removing bottlenecks and  blocking issues or improving speed of xdb_files
> access is just a matter of rewriting some code.

Code which has already been rewritten, tested, and deployed in the JCS.

> I'd rather expect someone respond
> "please, take your breath, we are working hard to solve these 
> problems". Or, that's the same if not better, "the problem is 
> maybe in concurrent locking of xyz. Stop complaining and go in 
> file xyz.c to see if you can do anything". 

While I have written some code snippets that might make it into the Open
Source jabber release code, I do not have commit access, and in general I
am no longer a programmer.  I do have some involvement in open source
projects, but for the most part my role is more in the area of evaluating
security and in assisting businesses in choosing the most appropriate
solution for their needs- often this means a commercial product.

In my opinion, the closed-source JCS has already solved the biggest
problems facing the open source project.  We (users and developers of 
the open source jabber server) are faced with a choice- reinvent the wheel,
code the same solutions that JCS has chosen, or find a different path to
the goal of a fast, stable, scalable server, such as the concept of a
'single user' server process as mentioned in your message.


> It seems to me that most effort is thrown in having a fully  multithreaded
> Jabber server. I think multithreading is only one aspect of the whole
> problem, and something I wouldn't wait one year to have. If the design is
> correct, all scalability problems of such an application can be solved by
> load balancing and server farming.

I am seldom impressed by scalability problems which are solved by throwing
hardware at a software problem.  Any solution should scale up with both
multi-server and multi-processor deployments, and in all cases should degrade
gracefully--  losing messages is never acceptable.


Kevin Kadow
MSG.Net, Inc.