I would like to know if the Smack API could be embedded in a server process type and used to process thousands simultaneous incoming messages. Is the existing thread mechanism efficient?
Would it be more efficient to create a component / message interceptor plugin in Wildfire in order to process a large amount of messages?
Hi,
would you please explain your use case a little bit more detailed?
Smack is a client API and it has a small memory footprint but it is of course not optimized as a client with a lot of connections. And it usually creates a connection to Wildfire so I wonder how it should handle a lot of incoming connections.
Writing a Wildfire plugin may be an option, depending on what you want to do.
LG
Thanks for the feedback.
The use case would be to react on specific custom message extensions independently of the used XMPP Server (preferred solution).
The listening component has an associated user id (i.e. messagelistener), all clients communicate with this user. Once the message receive, the extension pat is extracted and sent to a business layer for processing.
Therefore, we have a possibility to have an XMPP connection receiving hundreds to thousands of messages from many clients.
Is the threading model of Smack scalable enough to handle this? (basically, we would have a packetlistener object intercepting these messages).
Client 1, Client2, … Client N -
message-----> SMack MessageListener user with Packetlistener object.
I have also embedded SMack into a Spring container with IoC on packet listener, connection (server) detail… Form there this can be embedded into any known container. Anyone has the experience of doing so? Any constructive feedback?
Message was edited by: obrand