powered by Jive Software

Tinder 1.2.0 has been released

I’m happy to announce the release of version 1.2.0 of Tinder. This new version brings interesting new features, a number of bugs fixes and general performance improvement.

Recently, I published a document describing a problem that I dubbed Openfires Achilles’ heel. Tinder 1.2 introduces the AbstractComponent implementation, which will allow you to circumvent this problem easily. Additionally, AbstractComponent removes the need for the repetitive work that traditionally goes with implementing a full featured, spec-compliant component. Have a look at the Component Developer Guide for a detailed description.

Tinder 1.2 no longer depends on Openfire-specific logging. Instead, Simple Logging Facade is used, which will allow you to integrate with your existing logging framework easily. Finally, caching strategy and implementation have been modified to give you better performance.

A detailed list of changes can be found in the Tinder Release Notes. Did I mention that starting with 1.2 we’re releasing the code under the Apache 2.0 license?


My thoughts exactly

Wicked! Thank you, Guus, so much. Both for the document and for the new version of Tinder!

You’re welcome. Was that article of any help to you? It’s always interesting to hear stories from the trenches.

It was of immense help, actually. I’ve revamped my architecture so that vast majority of global IQ listeners are now implemented via a combination of an addressed internal (later, external) component and a switch that invokes specific IQ handlers.

Unfortunately, I still have to leave a global interceptor plugin that ensures that ALL authenticated resources of the recipient receive messages and not just the one with the highest priority. This really worries me from a scalability point of view. This problem is complicated by the fact that at least one of the resources associated with each user will not be directly Internet-accessible. I will have to use an http connection from the plugin to a gateway server that will later make a mobile phone push. Also, all the conversations on one of the resources will have to be strictly real-time syncrhonized with the second resource. So, I still have got enough on my plate to keep me awake at night

Hi Guus,

I’ve been working for the last few days on a component plugin that extends your AbstractComponent class and so far been a very enjoyable implementation experience. I’ve got only one issue/question which may be tangentially related to this new release of yours.

In the past, whenever I uploaded a new jar with an updated version of the plugin I was working on, the new code was immediately being executed. This doesn’t seem to be the case with my plugin that extends AbstractComponent. Even after I manually delete the old plugin data and upload the new one, the application behaves like it is still executing the old code. I’m really confused what could cause this behavior and it makes debugging really painful. Do you have any suggestions as to what could have caused this?

Hi Yuriy,

At this very moment, I don’t have the time to look into it (I’ll try to have a look tomorrow), but at first sight, it might be related to http://www.igniterealtime.org/issues/browse/TINDER-34

There’s a proposed solution in that issue. See if that helps you out.

Regards, Guus

Thank you, sir! It was indeed related. Works perfectly now.