I was wondering if someone provide the link to a binary distribution of CM v 3.1.1, or give me the information to get version 3.1.1 checked out of subversion?
Basically, we are currently running WF 3.0.1 (old, I know), and version 3.0.0 of the Connection Manager (which is still listed as the current version on the site’'s page), and are encountering a bit of a show-stopper issue where our Connection Manager is dropping users under load.
It appears to be the issue described under “JM-867 - Socket connections were closed under high load”, which is listed in the current changelog as being fixed in v3.1.1 of the CM module – the only catch is that I can’'t seem to find a release of this, or even a snapshot, anywhere!!
I would really like to get my hands on this as we would like to upgrade the connection manager machine to fix this issue ASAP, I.E. within the next 48-72 hours.
Much thanks in advance,
Matt
I think I’'ve found what I need to get the latest connection manager:
http://www.jivesoftware.org/fisheye/browse/svn-org/connectionmanager
Which directories do I need to retrieve, and then what needs to be done to compile into JARs and .exe (as it looks like that is what the next step would be)? Any assistance or even link explaining how to compile such Java source, to point me in the right direction, would be much appreciated.
Hey Matt,
Ok, so we forgot to update the Connection Manager’'s page with the 3.1.* release. I will try to do that today. Meanwhile, you have 2 options you can choose from:
-
Grab the code of CM 3.1.0 from SVN: https://svn.jivesoftware.org/svn/repos/connectionmanager/tags/connectionmanager_ 3_1_0
-
Grab the code of CM 3.2.0 from SVN: https://svn.jivesoftware.org/svn/repos/connectionmanager/trunk
CM 3.2.0 to be released on January 31 includes NIO support so each CM will be able to handle a lot more connections (e.g 30K). The code has been tested a lot and the only known issue is that stream compression is not working (yet).
Having said that, feel free to grab the code of any of those versions and then run ant all to build new distribution. In case that you don’'t have ant installed you can get it from here. Execute the ant command from the build folder. The output will be generated in the [connection manager]/target folder. If you are going to use CM 3.2.0 then you will not only need to copy all the target/lib/*.jar files but also the target/conf/manager.xml file.
Regards,
– Gato
Wow, Thanks! I will give that a try, and should post again by the end of today.
Are there any known issues with running a CM as new as 3.1 or 3.2 with an older version of Wildfire (3.0.1)?
I haven’‘t tried that but from the top of my head I would say that it should work. The exchanged XML hasn’'t changed so you should be fine. BTW, the CM 3.2 scales to a much bigger number but it is also a lot faster. That means that your server will have to handle a bigger load in the same time. Since you are not using Wildfire 3.2 (out by the end of this month) then your server may choke if you are placing a very big load on the server. We can say that the previous CM version was acting as a “delay” stage for the server.
Regards,
– Gato
We are running both the CM and the WF server on very large machines (both are dual core, 2.8ghz, and I think 2GB of RAM), and have a load of about 500 concurrent users at any given time – Would it be wise to make the jump to 3.2 given the hardware and maturity of development?
Basically, is 3.2 considered approaching or of equal stability to 3.1?
If so – given our hardware and expected load, should the server be able to handle what our CM would be throwing at it under 3.2?
I know you can’‘t give me definite figures on this sort of thing (especially when network and socket performance come into play), and system specs and performance can be touchy subjects ;). I’'m just wondering how much extra load 3.2 would put on our server compared to 3.1, and how much the versions may differ in stability.
Thanks for all the assistance
Oops, accidentally marked this as answered (although I’'d say it almost is).
Hey Matt,
For 500 concurrent users then any machine would be fine. Moreover, for 500 concurrent connections you can skip the CM and just connect the users to the server.
Regarding 3.2 stability code, I should say that it is pretty much ready for production. We usually check in code when it is ready to be used so that is why the nightly build versions are almost always usable. As I said, the only known issue with WF 3.2 and CM 3.2 is the stream compression feature that is not working. Besides that, you can give both WF 3.2 and CM 3.2 a test drive.
Regards,
– Gato
Awesome, thanks! I had a feeling that even somewhat of a junker could handle 500 users, but just wanted to be sure.
Due to decisions outside of my control, it has been decided to keep with running WF 3.0.1 for now – So, I will keep everyone posted with how the older version of WF plays along with CM 3.2.
Sounds like we should be back up to snuff in no time.
Regards,
Matt
Well, it looks like we won’'t be implementing the fix until next week, and will be upgrading to CM 3.1. Testing looks fine so far.
Message was edited by: MMorey
Well, we performed the upgrade to CM 3.1.1 while leaving the server at 3.0.1.
It appears that bug JM-867 is still occurring, where the CM begins misbehaving with ~250 users online, and begins to kick users. It is unclear whether it will still occassionally kick all users, as it did before, but now it appears to be “a bit better”.
I am letting you guys know, as perhaps JM-867 is actually resolved by upgrading both the server and the CM, not just the CM?
I am pushing for us to upgrade to server 3.1 to try to alleviate the problem now, as it seems to be the next logical step. Any feedback is appreciated, as always.
Regards,
Matt
Sorry, my mistake.
It looks like we grabbed the 3.1.0 release from the web site; I am guessing that 3.1.1 is only available via subversion.
We will probably take the connection manager out of the mix until we reach a set point of users (500 or 600 perhaps), and then grab whatever the latest stable release is at the time.
Regards,
Matt