Java Client Bug? Can't handle large number of rooms.

[cBroadbo]

We have an iPhone smartfox client app that has been deployed in production for over 1 year. We have a smartfox server(v1.6.2) that has between 3000-4000 dynamic rooms created by different PCs across the US.

Recently, we started an Android port of our iPhone client app and ran into some difficulty. The java Android client API connects and logs in just fine. However, it never receives a an onRoomListUpdate event. We also maintain a "staging" smartfox server. It is configured identically to the production server except that it only has about 12 rooms at any given time. Our Android client app connects and functions perfectly with that server.

Upon further testing I've found that if I set up a simple server(v1.6.6) with 300 static rooms, the latest SmartFoxJChat app will connect fine and functions just as you would expect. However, if I bump the number of static rooms to 350, the SmartFoxJChat app never gets a onRoomListUpdate call. The latest sample iPhone simple chat client running on the emulator functions completely normally. In fact, I was able to run the server with 10,000 static rooms and the iPhone simple chat app gets the room list, prints it to the console, etc. It dies soon thereafter, but at least it got the room list.

Is this an issue with the Java client?

Is there a setting I'm missing or perhaps a workaround?

It is very important that I find a solution to this issue because I can't deploy our product on Android without a solution.

Thanks in advance for your help.

Craig

[srirangr]

Hi,

Even I'm facing the same problem. We have 2 servers. I'm able to get the roomlist on one of the servers and not on the other. In fact, the onRoomListUpdate method won't be fired in the later case.

If you've found the solution to this problem, please let me know on my email id: srirangr {at} gmail {dot} com. Otherwise if this is a bug in the API. I'd ask the admins to please look into this.

Thank you.
Srirang

[cBroadbo]

Srirang,

Unfortunately, no one from smartfox bothered to do anything about this. Quite frankly, I'm surprised that other developers have not run into this issue as well. You will also notice that the Java API hasn't been updated since Feb. 11 2009! I'm telling you this because I don't think anyone is going to fix this anytime soon.

However, all is not lost. We were able to implement a solution. I'm probably a little foggy on the details, but the gist of the solution was to have a different zone just for logging in, with a CUSTOM login. This separate zone doesn't really have any rooms. The custom login doesn't automatically try to send you a room list. Upon successfully logging in through the custom login, we were able to log the user into the desired zone. At this point, we send the user a fake room list that just has one fake room in it. It is necessary for the client to have a room list because most of the API will not function without a room list. We then added a custom extension call or two that the client could use to retrieve a custom room list. In our scenario, we actually know the room names that we want in the room list, so we can ask SFS to send us a room list with just those rooms.

The bottom line is that we were able to implement a solution where a room list was not sent automatically. And we added some extension calls to query partial room lists that the Android client API could cope with.

I hope this helps.

Craig

[Lapo]

HI,
problems with the room list may arise if the list is huge and passes the message limit which by default is 32KB, if I recall correctly.
This has been asked many times in the forums and we provide two API settings that can be passed when launching the JVM. Please read here:
viewtopic.php?p=34865#34865

If this doesn't solve the issue then please report exactly which errors you get on both sides (client and server)

@cBroadbo:
The latest Java API for SFS1.x were released in April 2010

[cBroadbo]

Thanks Lapo for pointing out that it has been addressed.

Were you aware that your API Central lists the following about the Java API:
(New! Updated February 11th, 2009)? So you can understand why I wouldn't have downloaded a newer version.

Regardless, while the ability to increase the buffer size would likely solve the problem allowing the client to continue to function, you will still run into considerable performance issues with large room lists.

I've found that on the mobile clients large room list will cripple them pretty badly. For example on the iOS side, we had a room list of 3500+ rooms being sent and the delays processing these were horrendous. 10s of seconds. After some digging in the source I found that the room list message is converted to a DOM 2 or 3 separate times once it is received as it is passed down a series of method calls in raw XML form rather than the DOM form.

Obviously, if you could change the organization of your zones so you don't have too many rooms in each, this might not be an issue.

Our solution to have a custom login to a zone with no rooms and log the user into the desired zone (with only a fake room list sent) was a huge win. So much so, that we converted all clients (.NET, iOS, Android) to this system. Our situation may be a bit more unique than most in that we don't actually need to have room lists.

I can't say what the right solution for you is, but I just wanted to let you know there are techniques you can use to basically eliminate the need for room lists.

Craig

[Lapo]

You're absolutely right. Mobile devices resources are limited and, as with any other aspects (ie.g graphics, CPU usage), you have to be careful not to hog them completely.

With SFS2X we have introduced Room groups to avoid exactly this issue, but SFS1.x can partly emulate that by using several Zones as groups.