Wildfire 3.0.0

Hi All,

I’‘m looking to download Wildfire 3.0.0 for evaluation, but I can’'t find it in the SVN trunk or on the nightlies page. Is there a secret URL to download it?

The reason I’‘m looking at 3.0.0 is I’‘ve heard that 3.0 supports java.nio. Does 3.0 have any of the Pampero features? I really like Wildfire (using 2.6.2 right now), but I won’'t be able to deploy it until it has clustering. We have have tens of thousands of possible users, and from what I gather, Wildfire is single node only right now, and can support about 5,000 users per box.

I know devs hate this question (I’‘m one myself), but how long do you anticipate Pampero taking from this point? We looked at ejabberd, but Wildfire seems more extensible (I don’‘t know Erlang…) We can’'t launch our product until we decide on a scalable XMPP server for the backend.

Hi,

there is not yet a 3.0 available but the nightly builds contain already a lot of changes - I wonder if there is already enough Pampero code inside.

LG

Hey,

The NIO code has been merged into the trunk. It is not enabled by default, and, according to Gato not very stable yet. But, if you are willing to try it out and help us test out bugs on it, it would be very helpful.

Cheers,

Alex

I would be willing to give it a try. Are any clustering changes merged into the nightlies? I saw a posting from about a month ago that indicated that clustering was getting close to an alpha release.

I think Wildfire is really nice, but no clustering is a showstopper. Ejabber supports it, but it downright ugly and arcane to deal with in comparison.

Thanks,

Chris

Message was edited by: ckuske

Message was edited by: ckuske

OK, I have installed the nightly. Running OK so far, but I don’'t see any option to enable NIO (including in the src ZIP file)

Hi,

so you have a showstopper. Clustering is projected but Pampero is about scalability without clustering as far as I know. I wonder why no clustering is a showstopper, hardware errors are nearly never the cause for a failure. And a clustering implementation one can not really handle is probably even worse than no clustering at all.

LG

dombiak_gaston:

I would not recommend you doing that yet

xmpp.socket.blocking

set that property with a false value

in the admin console

restart the server after that

  • Blocking and non-blocking modes are supported.

  • By default blocking mode is used. Use the xmpp.socket.blocking

  • system property to change the blocking mode. Restart the server after making

  • changes to the system property.

Maybe I used the wrong terminology.

Once we hit max capacity on one Wildfire server, we need to be able to spread the load to other machines, as Pampero describes (using multiple connection manager boxes). Having multiple CM boxes and multiple backend servers would be the ultimate. We could need scalability to say 600,000 to 800,000 concurrent. Alot of users, I know.

FYI, setting the blocking property to false prevents my client from connected (Exodus), and also our own internal client. Turning it to true resolves it…

A part from NIO what else will 3.0 bring us? Are you already using the java 5.0 concurrent utils?

Hi ckuske,

Looks like it’'s going to be standard in 3.0:

-iain