Did you think about implements Serializable in classes of whack package? I meet some problems when I try to Cluster JiveMessenger by JBOSS Cache. I fear we (or you) must set JID… classes implements Serializable if we really want to make our IM Server clusterable, how do you think? .
That’‘s an interesting point. I wouldn’'t be opposed to making all the packet classes serializable. Can anyone think of a reason this would be a bad idea?
The JBoss Cache integration sounds interesting. Any details on the work you’'re doing?
Regards,
-Matt
Just a start, I put some objects(such as chatroom, etc…) into cache by JBoss Cache API, but we got a not serializable exception.
I agree with you, we need to decide which classes should be Serializable, but I think this is naturally decided by our cluster requirement.
by the way, I doubt to SocketReadThread, Blocking socket will let us meet thread overhead(in fact, I tested, and I got it), when Messenger has thousands of simultanous users, I get kinds of error, :).
So I fix the blocking Socket to nonblocking Socket by java.nio package. I made it. , could you give me some advices? maybe has some potencial technology problems or dangers?
thx.
I have to sleep, I have a interview this day at 10:00am. here, now, the time is 4:00am, , but in your place, perhaps you just had your lunch. heh…, I will come back for my issue, I disired discussion with you.
and I am sorry, Maybe, my question about blocking socket should be posted in JiveMessenger Support/Dev.
Best Regards
I think we could make all the packet classes serializable without problems. That should be a good start, although I’'m sure there would be other things that would need to be serializable such as sessions, etc.
On the socket code – I agree that we should probably take that discussion over to the Jive Messenger developer forum. There are a few approaches:
-
Use NIO as you suggest. I think this could be fairly straightforward except for the XML parsing part.
-
Have simple aggregator processes. This would be similar to external components from an architecture perspective. Basically, it would accept thousands of client connections, and then make only a single connection to a core Jive Messenger server. All packets from the users would be sent over the single connection to the central server (or cluster of servers). For even greater scaling, these aggregator servers could use NIO.
I really like the #2 approach. It should let a server scale to many tens of thousands of users in a simple way. If you combine that with NIO and clustering, that’‘s a truly powerful solution. I’'d be happy to discuss more.
Regards,
Matt