Hi,
is there any kind of documentation about server to server connections with jive wildfire? i have read several articles about howto set dns for ejabberd, but i haven’‘t found any documention for server to server connections with jive wildfire. i tried to activate both ports for s2s connection but they don’'t seem to connect automaticly to each other, so i think i missed an important part.
is there any quick howto available?
Regards,
Rouven
If you have enabled server to server properly on both servers, all you need is someone on one server to message someone on the other for the connection to establish.
For efficency reasons, s2s connections are only retained for a short amount of idle time.
ah okay, understood.
but with s2s it is not possible to login at server2 if the user account only exists on server1, right? i need a solution to cluster a wildfire server and not have the second server as standby, thats why i was asking. any ideas or experiences with that?
Thanks,
Rouven
An account on server 1 won’'t be recognized when logged in from server 2 with S2S. (Account on S1, attempt to log onto S2, logon fails)
You might want to consider the connection manager system for clustering.
Hey Rouven,
If I understood it right, what you’‘re asking is the support for virtual and multiple hosting in Wildfire. Unfortunately, Wildfire doesn’‘t support that. You cannot have more than a single domain on a single running Wildfire. You can have multiple sub-domains running though, but I think that’'s not what you want. Additionally, you even cannot have two Wildfires with the same domain connecting to each other.
There is however some effort mentioned in some other threads that tries to run two Wildfires for the same domain - an active-active configuration. The trick is to have them share the same database. The problem has been with the caching feature in Wildfire. The caching effects can be more confusing to you and your users. You can reduce the effects of caching but you can’‘t simply turn it off. If you run services in Wildfire like MUC, the problem can get even worse. If data integrity is not very much of your concern and you’'re not running MUC, than you might want to try it.
If clustering is indeed important to you, then the safest might be to have Wildfires running on active-pasive mode, sharing the same database.
But maybe clustering is not what you require at all. If your goal is only to support a large number of users that requires the number of connections larger than what your single host can support, than Connection Manager (CM) - an effort in Pempero Project - might be all that you want. With multiple CMs running, you can set it up so that your system is highly available. Still, the entire setup depends on a single Wildfire. The CM only acts much like a relay between your clients and Wildfire.
It’'s just my opinion
Hi,
yeah thats what i thought is the only way, too.
having multiple CMs as Load Balancer and a WS in Heartbeat Sync as failover. the only thing that is critical, is to have the CMs automaticly reconnect to the failover WS (on the same virtual ip). do u know if there is such a retry or reconnect feature already build in?
Rouven
Here’'s an excerp from the Connection Manager JEP:
h3. The server was stopped
…
At this point Connection Managers MAY be automatically stopped or may keep running and trying to connect to the server whenever it is started up again.
Logically the CM should have the feature but CM is still in alpha version, and so it may not have it yet. A simple test probably would do to verify that. Just let Wildfire and CM run, then restart Wildfire. …and further verify with it’'s source code.
hi,
cm’‘s are not retrying to establish the connection in this version. i’'ve checked that and opened a feature request in dev forums. thanks all for the help.
Hey rouven,
CMs will try to connect again to the server when a user connects to the CM or when a connected user sends a packet to the server through the CM. In other words, the reconnect is on-demand. The CM will keep trying to connect (on-demand) all the time until it is stopped.
Regards,
– Gato