May 2014

Uncontrolled Resource Consumption with Highly-Compressed XMPP messages

Multiple implementations of XMPP core protocol (RFC 6120) supporting stream compression (XEP-0138) suffer from uncontrolled resource consumption vulnerability (

Public XMPP Server Migration

Today we are beginning migration of our public XMPP servers.

Tigase XMPP Server 5.2.1 release

A maintenance version Tigase XMPP Server 5.2.1 has been released and it's available for download. As always - binaries are available for download in the files section on the project tracking system.

Tigase XMPP Server 5.2.0 final release

Finally Tigase XMPP Server 5.2.0, dubbed FTL - Faster Than Light, has landed in it's destination (that is our servers) and it's available for download. As always - binaries are available for download in the files section on the project tracking system. Sources are available in our code repository under the tag tigase-server-5.2.0 - tags/tigase-server-5.2.0. Maven artifacts have been deployed to our maven repository. To put a cherry on top we also run automated tests - successful results are available in our test page.

It could be expected that this version is not only blazing fast but is also packed with features - to recapitulate what has already been mentioned regarding 5.2.0 in previous posts   (Tigase XMPP Server 5.2.0 RC2, Tigase XMPP Server 5.2.0 RC1, Tigase XMPP Server 5.2.0 Beta3, Tigase XMPP Server 5.2.0 Beta2, Tigase XMPP Server 5.2.0 - FTL - Beta1):

Major additions to the Tigase XMPP Server in this release:

  • HTTP API with REST as the Tigase server component
  • Websocket support as a Tigase server connection manager
  • Message Archiving Component - XEP-0136
  • Socks5 Proxy Component with lots of interesting functions - RFC 1928
  • STUN Server Component - STUN
  • XEP-0198 - stream management extension with full support with ACK and Stream resumption. It is fresh but extensively tested already. If you do not have software to check it out or to test it, you can either use our JaXMPP2 client library which offers full support for the XEP or have a look at our Android client which can also make use of it.
  • XEP-0280 message carbons extension. Similarly to the above XEP full support for it is also included in our client side library and mobile messenger.
  • Tigase ACS - which includes main clustering strategy as well as MUC and PubSub cluster-enabled components! Those are not open source but we make them available for free for development and testing.
  • In addition to Derby, MySQL and Postresql Tigase now supports as well MS SQL Server.
  • Top notch improvements in security (v. Tigase XMPP Server - grade A software).
  • Inclusion of new PubSub 3.0.0 which features performance improvements due to reworked schema (v: PubSub database schema conversion),
  • Switched JDK compatibility to JDK7. Number of issues in Tigase server were related to bugs in JDK6 and patching them and creating workarounds was taking up resources. Therefore we decided to switch over to JDK7 which is now required minimal version.

Server configuration the XMPP way

Controlling and configuring the server from your Jabber/XMPP client was always one of priorities in Tigase project. Using service discovery and ad-hoc commands you could browse server statistics and change settings for modules loaded into server. Upcoming 2.9.0 version offers next feature - adding new components to the running server with ad-hoc commands. This gives complete control to the server admin over configuration of the running Tigase server just from his Jabber/XMPP client.

Jabber/XMPP server testing tool

What is the ideal Jabber/XMPP server testing tool? Well, the question actually should be: What is the ideal testing tool in general? There are also helper questions: Why do programmers not test their code properly? Why do programmers not write unit tests for their code? What tool for testing would programmers want to use? I was thinking about this subject for some time already because testing is important part of Tigase server development. Test Suite is Tigase subproject to which I dedicate significant development time and still I noticed my tests were not up to date. Some new extensions (XEPs) I added were not covered by tests even though testing framework is created by myself. How could I expect others to use my testing framework when even I don't use it? I asked myself all questions from the beginning of this article to rethink my approach to tests and to possibly re-design or re-implement my framework to the form which I would use on daily basis. It seems to me that answer to above questions is quite simple: I would use test framework on daily basis if it made my live easier. If it simplified my development work and basically if I had less to do.... The last sentence is a key: If I had less to do..... So tests should decrease development effort. The ideal solution for Jabber/XMPP server would be a tool which could take an URL to XEP as a parameter, I press a button and it executes test against specification. As a result I could work just on server code until the test against the XEP returned success. In this way I would have really much less work to do because I wouldn't need to start a dozen Jabber clients and test the functionality in each client, possibly even use XML console to track whether the input from the server is correct. It took just a few days for me to extend test suite...

Migration on the new server

If you can see this message it means that DNS change has been populated and you access Tigase service on the new server. The old machine was quite underpowered and couldn't cope with the traffic and all services running on The new server with Core2Quad CPU, 4GB RAM and 500GB HDD in RAID1 mirror should be enough for our needs. If you see something not working correctly or some unexpected behavior please let me know. The old machine is still alive with all services working on it so some people may still connect to the old server while some other for who DNS changes was updated earlier may connect to the new server. I am going to shutdown the old machine within a few days.

Next release...

The Internet connection was down and there was no access to the project website. We haven't been idling however. We have spend all the time on hard work and a new much improved release is expected soon after FOSDEM. Please come back in 2 next weeks for the new release. In meantime you can access our SVN repository to build your own version and here is a brief Changelog with changes you can expect in new release:
  1. Bosh improvements - most of our development time was spent on the Bosh component. It is already not an experimetal component. It now well tested and solid component with all the major Bosh features implemented and most of the minor features included too.
  2. Multi-CPU and multi-core support improved - I have re-implemented some parts of the server for a better support for multi-cpu and multi-core systems. You can now expect much better throughput in Tigase on such systems.
  3. Dynamic rosters support - you can now implement your own simple class to load/generate own whole roster or parts of the roster for selected users in your system.
  4. Presence subscriptions improved - improved handling presence subscriptions in terms of performance and a few minor but annoying bugs fixed.
  5. Lots of bugs fixed....

Tigase is back!

Tigase website and the service disappeared for over 2 weeks. I am sorry for all the inconvenience and problems it could caused and for a disruption of the XMPP/Jabber service. We have now a business class Internet connection with 24/7 support and I believe it won't happen again. Please let me know if you notice something wrong with the website or the service. Internet provider has changed and our network configuration has changed too, so there might be still some outstanding issues to solve. We had a problem with our Internet connection provider who accidentally disconnected our wire during the maintenance. It took them over 2 weeks to fix the problem and in the meantime after calling the technical service every day hearing the same: "Might be fixed tomorrow or in a few days but I can not guarantee it won't take a month." I decided to change the Internet provider. You can read the full story on my blog website. I am thinking again of outsourcing the server hosting....


Jabber/XMPP protocol is based on data stream embedded in XML. Single XMPP connection is like a single XML document. XML is essential for XMPP and all its services are built on top of it. Whole XML stream is generated, sent, received and parsed by Jabber applications and human usually don't see any markup. Thus usually XML stream processing is limited to what applications might expect in this stream. Usually there are no XML comments in stream, no processing instructions. All the XML data usually forms correct XML document and because of dynamic nature of XMPP stream applications don't validate stream against XML Schema or DTD. It does make sense to use kind of simplified XML parsers which can process only limited set of XML features. It is especially important for server side processing where performance of any operation may impact overall server throughput. How far this simplification can go?


Get in touch

We provide software products, consulting and custom development services

Tigase, Inc.
100 Pine Street, Suite 1250
San Francisco, CA 94111, USA
Phone: (415) 315 9771

Follow us on:


  • Remember when robots were mentioned? Tigase IoT One is helping this PiBorg conduct autonomous navigation and posit… 14 hours 18 min ago
  • Food for the imagination: IoT One Cloud from Tigase can use ICs to create and control custom circuits! Anyone have… 3 days 14 hours ago
Back to Top