I am using Smack to connect an application server (client) to an XMPP instance. Since it is an application server there is a potential for thousands of connections to happen concurrently. I was going to use a Singleton for a connection handle and/or build a connection pool (like with JDBC).
Is this the right way? Anyone built a Singleton or Connection Pool for XMPP? Pros/Cons?
I am guessing that it may work but it means everyone will be sharing the identity associated with a single connection. I guess it really depends on your use case.
In this case the app server IS the user so there is no identy issue. In my use case XMPP is being used as a back channel communication to clients. Back channels happen when the client makes a “fire and forget request” to the app server and some time later the app server needs to send a message back to the client. The app server contstructs a message (getting end-point client from a lookup table) and forwards to the XMPP Server. We are using this instead of app server long polling (Comet)
Ah, I have solved the same use case by using JMS and an OpenFire plugin. We were using JMS anyway so it made sense to simply make a plugin which was a listener.
In your case, I think it will work, but you would have to make each connection use a different resource for login so even though the user (server) is the same, each connection has a unique full JID. Obvously your clients only care about the base portion which identifies the server. Of course if the client only uses XMPP for this single purpose anyway, then I guess the from is irrelevant to the client end altogether.
Yes each connection has a unique JID (based upon lookup table). For example when the client logs in it does this first to app server the AuthN authority. It gets a token and then connects to the XMPP server. Both servers are sharing the same credentials. The lookup table contains client information which is used to construct the JID. The lookup is actual a pairing table (mapping) between the client and another device it is paired with. Without compatable JIDs this breaks