This problem can get more complicated if you depend on DNS SRV records to identify the XMPP server in your network. Google tries to connect to your hostname, instead of your domain name, which is a significant difference in these cases. Wildfire drops these connections, because ‘‘host name’’ does not equal ‘‘domain name.’’ You’'ll see a lot of
“Closing session due to incorrect hostname in stream header.” messages in warn.log if you’‘re suffering the same problem. As a side-effect of this problem, Google presence stanza’'s are routed to only one client per user: the client with the highest priority setting.
I’‘ve talked this over with Gato off forum, and he’'s talking to a number of people to get this fixed (it turned out to be a misinterpretation of the XMPP Core specification by Google, not Wildfire).
Returning to the problem at hand: wildfire checks if a connection to or from a federating domain already exists. If it does, it denies the second attempt. I’‘ve turned off this check by commenting out lines 426 to 435 in the org.jivesoftware.wildfire.server.ServerDialback class (you’‘ll have to make a few minor modifications to be able to compile again). As far as I can see, it works fine. You’‘ll see more than one incoming connections for google. Make sure that you set a timeout value for server connections though! You’'ll swamp your server in idle connections otherwise. (Timeout values for server connections can be set in the admin panel, under ‘‘Server to Server.’’ The default value is 30 minutes, I think).
Because I’‘ve been suffering from both problems I described here, I can’‘t be sure that my last solution works 100%. It’‘s hard for me to pinpoint which problem is caused by what cause. I can only say that things -seem- to work a little bit smoother when you modify the code to allow for multiple connections, but I won’'t recommend doing this on a production server without further testing.
Well, that’'s about it I think.
– ‘‘another community member’’