Clint, I think you do not need to modify the code to reduce or avoid excessive presence traffic. Tigase with ACS offers such an option out of the box. Wojciech will provide details on this.

Wojciech, please make sure this option is documented somewhere and provide a link to the documentation.

Clint,

a couple of comments:

• When you are trying to build a component for the stable server version you should try to match sources / versions to those included in the release; in principle released stable versions are in the stable branches (v. stable muc branch) or tag that was associated with the revision

• MUC Component uses Tigase Component Framework and you don't need to recompile it to use different modules (in your case @PresenceModuleNoBroadcast@) - you can simply configure desired class, which can be in different binary, vide [[Configuration#Modules | Modules configuration]]

• If you want to suppress Presence broadcast you can use build-in Tigase future and room configuration option - after enabling it you can select which (if any) affiliations should receive presence broadcasts (own presence will always be send to the user to avoiding breaking clients), vide [[Configuration#Room-Configuration-options | Room configuration options]]

Hi,

I've used your newly documented configuration parameters to get the MUC component to suppress presence broadcasting as desired. Thanks for that!

I have also followed your instructions to clone latest source code for the MUC component. I am able to build a MUC component JAR with the source you referred to in your original answer but continue to get the error below when I try to use it in our environment running "tigase.muc.cluster.ClusteredRoomStrategyV2"

java.lang.AbstractMethodError
     at tigase.muc.Room.fireOnMessageToOccupants(Room.java:217)
     at tigase.muc.modules.GroupchatMessageModule.sendMessagesToAllOccupants(GroupchatMessageModule.java:379)
     at tigase.muc.modules.GroupchatMessageModule.process(GroupchatMessageModule.java:287)
     at tigase.component.modules.ModulesManager.process(ModulesManager.java:119)
     at tigase.component.AbstractComponent.processPacket(AbstractComponent.java:354)
     at tigase.muc.MUCComponent.processPacket(MUCComponent.java:379)
     at tigase.muc.cluster.MUCComponentClustered.processPacket(SourceFile:76)
     at 
tigase.server.AbstractMessageReceiver$QueueListener.run(AbstractMessageReceiver.java:1424)

This JAR will work fine with the default clustering mode.

Furthermore, our "tigase.muc.cluster.ClusteredRoomStrategyV2" setup

works perfectly with the JAR that is contained in your distribution.

So it doesn't seem like the code you have in master for MUC is the same

as what you are distributing bundled with the server?

Or maybe I am doing something wrong?

Or maybe there is some other way we can get to where we are trying to go?

What we are trying to do is remove or disable the "delayed" data from

MUC room messages. The iOS library we are using doesn't like them and

frankly we don't need them. So maybe there is a way to suppress those

via configuration?

Any help you can offer would be tremendously appreciated.

Thanks,

Clint

On 5/7/15 5:48 PM, support@tigase.org wrote:

From your stacktrace:

     at tigase.muc.Room.fireOnMessageToOccupants(Room.java:217)
     at tigase.muc.modules.GroupchatMessageModule.sendMessagesToAllOccupants(GroupchatMessageModule.java:379)

it looks like you are still trying to build latest master/development sources (in the stable branch GroupchatMessageModule ends at line 395 and generally your stacktrace doesn't match sources from stable branch). Please checkout stable branch and build it. As git doesn't allow linking to particular version/source of the repository you need to clone complete repository and then manually checkout desired branch (or commit) hence link on that repository page is the same for master and stable branches.

Wojciech,

Thank you for pointing out my silly mistake.

Once I downloaded the @stable branch of the MUC code, I was able to successfully build and deploy with the changes we wanted and it all worked!

Thanks for your responsiveness,

Clint