I found issues with not properly configured ACS and wrong PubSub schema, however I was not able to replicate issue with blank page. This is most likely caused by long time used by loading schema to DB - if you stopped it, then schema loading could fail.

I also added proper ACS configuration check on server side (until now it was any done in JS) and added warning about disable JS on setup site - just in case.

Next SNAPSHOT build should contain this changes.

All issues fixed.

%andrzej.wojcik the first issue showed up again as I was installing MSSQL DB this week. I assumed the fix was for all databases.

• Used the web installer today for cluster mode. Installer did not generate an --sm-cluster-strategy-class line in init.properties. It did include --cluster-mode=true.

Can you check the other databases please.

I used latest build and all works fine.

You are right - --sm-cluster-strategy-class - is independent of database type used.

--sm-cluster-strategy-class line in init.properties is generated only if Tigase Advanced Clustering Strategy (ACS) Component is enabled.

Using of --cluster-mode=true without --sm-cluster-strategy-class line is correct as default clustering is used. (clustered mode enable with Tigase ACS disabled)

I tried to replicate this issue but i'm not able - config is always generated correctly.

I suppose there may be some specific thing you do that causes this issue, but I'm not able to find it.

Eric, please close if issue is resolved.

Just used the installer to setup a clustered installation. Shouldn't muc default to

tigase.muc.cluster.MUCComponentClustered, and pubsub to tigase.pubsub.cluster.PubSubComponentClustered ?

config-type=--gen-config-def
--cluster-mode=true
--virt-hosts=tpub.xmpp-test.net
--admins=admin@tpub.xmpp-test.net


--debug=server

--user-db-uri=jdbc:derby:tigasedb;create=true



--sm-plugins=+jabber\:iq\:auth,+urn\:ietf\:params\:xml\:ns\:xmpp-sasl,+urn\:ietf\:params\:xml\:ns\:xmpp-bind,+urn\:ietf\:params\:xml\:ns\:xmpp-session,+jabber\:iq\:register,+jabber\:iq\:roster,+presence-state,+presence-subscription,+basic-filter,+domain-filter,+jabber\:iq\:privacy,+jabber\:iq\:version,+http\://jabber.org/protocol/stats,+starttls,-msgoffline,+vcard-temp,+http\://jabber.org/protocol/commands,+jabber\:iq\:private,+urn\:xmpp\:ping,+pep,+zlib,+message-archive-xep-0136,+amp

--comp-name-1=muc
--comp-class-1=tigase.muc.MUCComponent

--comp-name-2=pubsub
--comp-class-2=tigase.pubsub.PubSubComponent

--comp-name-3=http
--comp-class-3=tigase.http.HttpMessageReceiver

To be honest I'm not sure about this. I think that %kobit or %wojtek should confirm.

From what I know PubSub and MUC clustered versions will work only if ACS is enabled and in your configuration ACS is disabled. In this case we do now provide clustered versions of PubSub and MUC components in configuration as it would fail to start without ACS.

In clustered mode without ACS there should be plain (single node) components used and entries for them were generated in your config, however on second and next node you would need to configure virtual components instead of PubSub and MUC, so traffic for PubSub and MUC will be routed to single node on which nonclustered version of PubSub or MUC is running.

I think possible solution would be verification if the clustering and ACS is enabled while enabling MUC/PubSub - if not then we could show some information that clustering was enabled but ACS is missing (during installation)?

What's worse, in IzPack installer we by default enable cluster-mode and PubSub/MUC in non-clustered versions...

Enabling ACS should imply enabling clustering. And I agree that MUC/PubSub clustered should require prior enabling ACS.

In IzPack, the installer was created when there was no clustering for MUC/PubSub, and this was never fixed. However, I think we can ignore the IzPack installer as we will be removing it anyway.