Why Real-time Collaboration? – Creately

After a prolonged wait we have finally taken up the time to implement Real-time Collaboration for Creately. Right now the feature is in Beta and can be used by anyone who wishes to take it for a spin. The real question is why did we not do it all this time? and why have we finally done it?

For those who dont know what im talking about, real-time collaboration is the concept of being able to edit a document/file at the same time from multiple different computers while seeing changes from each editor in real-time.

It’s true that the buzz around real-time collaboration was really a while before. But thats all about the coolness of being able to work with people located in a different parts of the world at the same time on the same document and see the changes happen like magic. It was a big deal for application developers to get this working in their tools and specially when it is a cloud app. We felt the same way back when we started Creately. We had to have it because it was cool and it can create lots of buzz. But we were blocked by many factors.

What does the user really want?

From the early days we have prioritized the road map of the product based on what our users wanted. This is one of the key success factors of Creately. We payed lots of attention to support requests, discussion forums and user votes on features. This almost always decided what went into each release of Creately. Real-time collaboration as a feature did have lots of attention as well from our users. But it was not always the burning problem. Smooth collaboration was a burning problem but that didn’t always mean real-time is required. We learnt this as we started improving the collaboration features. Users wanted to be able to easily share to edit or view, to easily embed and interactively view the diagram, to be able to discuss and notify users on changes and work together. We built features that enabled all of these. Real-time collaboration always seemed like that “cool” feature and didn’t convince us a as a burning problem over most other requirements in the diagraming space.

Revenue does matter!

Thats right, you know it! Real-time collaboration as a feature didn’t make revenue sense as much as most other development we have done around Creately. Series of the initiatives we did were to deliver Creately to bug tracking and wiki platforms like Confluence, JIRA and FogBugz and also build a desktop version of Creately. It would only make sense to hit the numbers while building and delivering great products. This added on to the delays.

Why now?

Creately is doing GREAT! While things are going well we wanted to get this feature out, a long lasted wish. But most importantly as we improved collaboration features we realized always something was missing. Collaborating in real-time is not about seeing the changes and feeling the magic (so to speak), but getting something done fast and getting it done easy. The real utility in words doesn’t seem a big deal, but when you are really using it you feel the difference. It makes life just so much easier.

Lets think back. When we didn’t have cloud applications it was all emails going around with attached files. Soon you had multiple versions going around with different users edits on them. This was solved by collaborating online. You had one file that was being changed. But still you had to go back and forth after making the change to communicate with the team. This can lead to lots of time wastage if you are not communicating well. With real-time you are seeing what’s happening and ideas are communicated well and all in one session you get to create and communicate what you want. You really dont have to worry much. To feel the difference, it has to be experienced.

We are glad we did this and we have lots more planned for this year. Stay tuned!


Scaling BlazeDS with Servlet 3 (Concurrency)

One of the well known issues of BlazeDS is it’s limitation in scaling. To be more specific, if you are using BlazeDS for HTTP steaming using AMF, the number of concurrent streaming connections will be limited to 100s. The exact number would be dependent on multiple factors such as the capacity of the server and configuration settings on Tomcat or whatever the application server you are using. When it comes to streaming each connection would be opened and held until the client closes or the connection times out. In the case of BlazeDS this directly relates to the number of threads consumed due to how Servlets operate. Servlet consumes a thread per request and holds the thread until the request is committed. During streaming, a request is kept open throughout the streaming session which makes the servlet hold the thread through out. This particular problem cannot be solved with servlet 2.5 or before due to the limitation in Servlets itself. However Servlet 3.0 supports asynchronous requests which can be utilized efficiently to scale the same servers to support 1000s of concurrent connections.

Up to BlazeDS 4 there has not been support for endpoints that utilizes servlet 3.0. BlazeDS 4.0 turnkey ships with Tomcat 6 which uses servlet 2.5. There has been rumors that BlazeDS 4.5 will have endpoints that utilize the capability of Servlet 3.0. Still this is just a rumor and cannot be depended on. Given the current state of affairs and the growth of other frameworks and technologies I would not expect much. There have been solutions for the problem that uses various technologies and my picks are below.

  • MuleRTMP – A Google code project that uses the capabilities of Red5 streaming server and streams to AMF clients over RTMP.
  • A polling solution that uses Jetty 7 Continuations to provide an endpoint for BlazeDS
  • The Farata Systems’ solution which uses again Jetty 7 and Servelet 3 to provide a streaming endpoint for BlazeDS.
  • blazeds-servlet3-support – Another Google Code project that is a simple BlazeDS streaming endpoint that utilizes Servlet 3.

I have been personally working on the blazeds-servlet3-support project by contributing code. Right now the code looks quite messy but it works. I had to fix some of the issues and currently it is able to reliably stream messages on Tomcat 7 without causing any trouble. What this does is simply utilize the Async capability of Servlet 3 to isolate all the pushing functions into one single thread. Requests are handled and then immediately the Context of the request is handed to a the pushing thread, enabling the thread that handled the request to complete and return to the pool. This approach pretty much would allow your same server that was limited to 100s of connections to boost up to 1000s of connections. This is however not tested yet and will be done once I have completed work on the endpoint. I will run some load tests and post it up. If you wish to give this a test run here is what you need to do.

  1. Install Tomcat 7 and Blaze DS 4. The turnkey install of BlazeDS 4 is not going to work since it ships with Tomcat 6.
  2. Once you have Tomcat and BlazeDS working fine, change the Tomcat Connector configuration to use the NIO connector instead of the BIO conntector. The setting is in the server.xmland should be changed as follows.
    <!--<Connector port="8400" protocol="HTTP/1.1"
     connectionTimeout="20000" redirectPort="8443"/>-->
    <Connector connectionTimeout="20000" port="8400" 
     protocol="org.apache.coyote.http11.Http11NioProtocol" redirectPort="8443"/>
  3. In your Tomcat BlazeDS application context change the Servlet configuration to allow asynchronous capability for the MessageBrokerServlet. This should be done in the web.xml as follows.
  4. Copy the compiled blazeds-servlet3-support jar file to the WEB-INF/lib folder of the context.
  5. Change the WEB-INF/flex/service-config endpoint as follows.
    <channel-definition id="amf-stream" class="mx.messaging.channels.StreamingAMFChannel">
      <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/streamingamf" 
  6. Restart Tomcat and you should be good to go!

Since I am continuing to work on this I would very much appreciate any feedback you might have. Please let me know your thoughts in the comments.

Startup Weekend – Bangalore

Its about time that I forced myself to throw in another post specially right after the Startup Weekend in Bangalore, India. Yeah, I was there. flew to Bangalore just for the event over the weekend with Chandika. I have to admit, it was worth every bit.

What is this Startup Weekend you ask? it is an intense 54 hour event which focuses on building a web or mobile application which could form the basis of a credible business over the course of a weekend. The weekend brings together people with different skill sets – primarily software developers, graphics designers and business people – to build applications and develop a commercial case around them. The Bangalore event was at the Microsoft office.

Despite the reputation Startup Weekend had, initially when myself and chandika set out to the event I was quite skeptical about if there was going to be enough participants or if the caliber of the crowd was going to make it challenging enough. I was worried if it was going to be a waste of a weekend than an eventful one. For us it was a weekend to break away from the post startup life we are in with Creately (still awesome!) and to re-experience the exuberant rush and energy produced in the early days of a startup.

So on thursday we went in and as the event started it was a promising crowed with the organizers making way to get started on a very busy weekend. I was stunned by the informality and counter-culture nature of the event. Even-though initially it all seemed unstructured and rebellious, it set the right spirit in the environment and among the participants. As the pitching session began I realized that almost everyone in the room had something they wanted to pitch. I was impressed by the quality of ideas that were being pitched. Even-though not many of them were very internet/cloud focused, I found quite a few interesting idea’s that I wanted to be involved in. I had initially gone in prepared to pitch an idea of mine, but by this time given the number of ideas that were being pitched I was convinced that I wanted slide into a much more executing/hacking role than my usual planning/managing role during this event.

Within few hours teams had formed and ideas had come together and people were already in intense conversations about their respective startups. The day had extended and I was too in a battle for balance in getting our startup towards victory. I was working with a energetic bunch lead by Jagat Iyer a smart, articulate and very passionate entrepreneur. Enjoyed every moment of being with the team working towards perfecting the idea of Shasthra (thats the product we were working on). This continued along with more planning and executing towards the five minute pitch that had to be done on Sunday evening. It was pressure blended with excitement and motivation amongst very little eating and sleeping. The next two days were spent meeting new peers and mentors talking and validating all aspects of the business at the meantime preparing for the final pitch. Having built a globally successful product, I was very familiar with the situations and problems we were coming across and was able to enjoy and work with the team on solving and overcoming all of it.

I was very impressed with the committed organizing team namely Pankaj, Chidambar, Gaurav and many others who were sticking along at all times making sure everything was taken care of in a timely fashion. There were talks about possibly having a Startup Weekend in Colombo this year as well. However there is nothing firm so far on this and we are looking forward to make it happen if Startup Weekend is willing to. All in all it was a splendid weekend full of energy and I can’t think of anything that was not right about it.

Startups forever!!