Hi,
Is it possible to run an external component in the OpenFire server’s domain and not in a subdomain? The Component spec (XEP-0114) doesn’t require a component to be segmented in a subdomain so I’m wondering how to do this with OpenFire. I currently run a component against the domain on a ejabberd server but am considering moving to OpenFire
Digging through the documentation and source code indicates that OpenFire requires a Component to run in a subdomain but I’m wondering if any of you have had experiences contrary to that.
Thanks,
Steve Jenson
Hey Steve,
I guess I’m confused with your question. Each component has to have a unique address and it has to be different from the address of the server. In the case of Openfire, addresses of components are of the form of subdomains of the XMPP domain. It is not possible to have an external component connected to an XMPP server and be offering a JID that is unrelated to the XMPP server.
Hope that helps.
Regards,
– Gato
Sorry for being unclear. What I would like is to run an openfire server on domain example.com and to have a component that can listen to all packets sent for any user on example.com
Thanks,
Steve
Hey Steve,
The functionality that you are describing is not covered by XEP-0114: Jabber Component Protocol. Based on that XEP each component will have its own JID (i.e. XMPP address) and packets will be sent to the component only if the TO attribute of the packet is the component address.
However, you might achieve what you are looking for using ad-hoc commands. AFAIK, the XMPP does not have a XEP (i.e. a standard) for doing this so you will have to do it using a custom ad-hoc command. Openfire includes an ad-hoc command that a component can execute to get copies of presence, message or IQ packets. If you want to filter by user JID then you will need to create your own ad-hoc command based on the one I just described or do the filtering in your component.
Regards,
– Gato
The XEP says nothing about the relationship between the domain of the server and the JID of the component, only that the server has to recognize it and forward packets to it. OpenFire has decided that this means only to allow components onto subdomains which is an ok choice but it does limit how useful components are. With ejabberd, I’m able to register a component to get packets for every user of the system by making it’s JID equal to the server name. That’s how we built twitter@twitter.com. Unfortunately, ejabberd hasn’t been able to withstand the load we’ve put it under and OpenFire has done a lot better so we’ll have to move users to use twitter@im.twitter.com with OpenFire.
BTW, I load tested an instance of OpenFire to 5k qps recently, I was quite impressed! I used a 64-bit Java 6 and gave it 12G of heap space.
Thanks,
Steve
Hey Steve,
The XEP says nothing about the relationship between the domain of the server and the JID of the component, only that the server has to recognize it and forward packets to it. OpenFire has decided that this means only to allow components onto subdomains which is an ok choice but it does limit how useful components are. With ejabberd, I’m able to register a component to get packets for every user of the system by making it’s JID equal to the server name. That’s how we built twitter@twitter.com.
That is very interesting. BTW, I never interpreted from XEP-114 that a component could register using the JID of a user. Moreover, I also never interpreted that the server would copy traffic sent to the user’s JID to the component. Anyway, I think that is a good idea and some official XMPP extension should document it.
Unfortunately, ejabberd hasn’t been able to withstand the load we’ve put it under and OpenFire has done a lot better so we’ll have to move users to use twitter@im.twitter.com with OpenFire.
I’m happy to hear that Openfire is working fine for you. I had no idea that you were working for Twitter and that you were using Openfire. I would be more than happy to help you with this initiative. Let me know if you are running into troubles or need some extension.
BTW, I load tested an instance of OpenFire to 5k qps recently, I was quite impressed! I used a 64-bit Java 6 and gave it 12G of heap space.
Nice to hear that. Openfire scales very very well as you saw in your tests. Openfire uses Apache MINA that is a NIO framework. NIO uses the OS infrastructure for handing network sockets and traffic. That means that depending on the OS you are using you can get better results. BTW, which OS have you used for your tests?
Thanks,
– Gato
We used RHEL 5 with a 2.6.18 kernel. We’re using Java 6 which uses the epoll SelectProvider by default.
Thanks for the offer of help! Hopefully things will continue to go well and we won’t need it.
Best,
Steve Jenson