Alex Tkachman

While Kotlin programming language prepares for the public early access program I want to share with you one an example how easly it can be used with existing Java codebases. This short note does not intend to teach the reader how to use Kotlin but only to make him/her intersted to learn. We will create small toy application using Kotlin and the charming Guice framework. The application is nothing more than the usual "Hello, World!" but it contains an application service and logging service and each service will have two incarnations - for testing and for production use. Let us start with an abstract LoggingService. It will be an abstract class with only one abstract method to output the passed string. Most probably the code below does not require much explaination. abstract class LoggingService() { abstract fun info(message: String?) } Now we will define a simple implementation, which prints the given message to the standard output class StdoutLoggingService() : LoggingService(){ override fun info(message: String?) = println("INFO: $message") } override modifier tells the compiler that the method overrides some method of a superclass. Note also string interpolation Now we will create a little more sophisticated implementation, which we will use in production :) class JdkLoggingService [Inject] (protected val jdkLogger: Logger) : LoggingService() { override fun info(message: String?) = jdkLogger.info(message) } [Inject] annotation on constructor tells Guice how to create JdkLoggerService. val on constructor parameter asks to create final property initialized by given value. var asks for non-final one and neither of them define simple constructor parameter Now we are ready to define the abstract application service and both implementations of it for test and production use. abstract class AppService(protected val logger: LoggingService, protected val mode: String) { fun run() { logger.info("Application started in '$mode' mode with ${logger.javaClass.getName()} logger") logger.info("Hello, World!") } } class RealAppService [Inject] (logger: LoggingService) : AppService(logger, "real") class TestAppService [Inject] (logger: LoggingService) : AppService(logger, "test") Note how elegantly Kotlin allows us to define properties and pass values to superconstructor Now we go to more interesting part - creating min-DSL for Guice. But let us start with how we want our application to look like. fun main(args: Array) { fun configureInjections(test: Boolean) = injector { +module { if(test) { bind().toInstance (StdoutLoggingService()) bind().to () } else { bind().to() bind().to () } } } configureInjections(test=false).getInstance ().run() } There are few things to notice here We use local function to configure injections. It is not necessary but allow some nice code grouping. Return type of function configureInjections is inferred from it's body (call to finction injector - root of our DSL which we will define soon) We call configureInjections using named arguments syntax. It is not necessary in our case but very convinient when we have many parameters and some of them are optional. Now it is time to define simple parts of our DSL. It will be three extension functions for some Guice classes. fun Binder.bind() = bind(javaClass()).sure() fun AnnotatedBindingBuilder.to() = to(javaClass()).sure() fun Injector.getInstance() = getInstance(javaClass()) Please read about extension functions in Kotlin documentation Note in variance used in function 'to'. Please read about generics and variance in Kotlin documentation. It is really interesting javaClass() call is Kotlin standard library for Java (remember that Kotlin can be compiled for other platforms like javascript as well) is equivalent to T.class in Java. The huge difference here is that in Kotlin it applicable not only to real classes but also to generic type parameters (thanks to runtime type information). Call to method sure() is Kotlin way (soon to be replaced by special language construct) to ensure non-nullability. As Java has not notation of nullable and non-nullable types we need to take some care on integration point. Please read amazing story of null-safety in Kotlin documentation. Finally we are ready to most complex part - definition of method injector. fun injector(config: ModuleCollector.() -> Any?) : Injector { val collector = ModuleCollector() collector.config() return Guice.createInjector(collector.collected).sure() } It has one parameter of type ModuleCollector.()->Any? which means "extension function for ModuleCollector(we will define ModuleCollector few lines below), which does not accept any parameters and returns value of any type potentially nullable" The implementation is very straight-forward we create ModuleCollector we use it as receiver to call given configuration function we ask Guice to create Injector for all modules configured (consult Guice documentation for details) This is extremely powerful method of defining DSLs in Kotlin As we saw above we call method injector with function block expression. The fact that parameter is extension function makes all (modulo visibility rules) methods of ModuleCollector available inside function block. The last part of our DSL is definition of ModuleCollector. It contains internal list of collected modules and only two methods method module - uses variation of the same extension-function-as-parameter trick - we use extension function to implement method of anonimous class. Please consult Kotlin documentation on object expressions method plus - overrides unary plus operation Please consult Kotlin documentation on operator overloading. It is very important to note that this method is both extension method and member of class ModuleCollector. It allows very good context catching on call site. In our case above we call this method inside extention function with ModuleCollectoror receiver and apply it to Module created by call to method Module. class ModuleCollector() { val collected = ArrayList () fun module (config: Binder.()->Any?) : Module = object: Module { override fun configure(binder: Binder?) { binder.sure().config() } } fun Module.plus() { collected.add(this) } } We are done. I hope that was interesting. This note is a very brief and non-detailed introduction on goodies of Kotlin. If this has motivated you to read more about Kotlin then my goal is achieved. Thank you and till next time!

We are staying in front of new world - all major browsers either support already or plan to support in next major version HTML5 (not in scope of this article) & WebSockets (main subject of the article). In 6 to 9 months we as application developers will have in our hands extremely powerful client side tools to build new generation of the Web. But are we ready on server side? And if not, what the point in having powerful and reliable communication channel between browser and server and non-utilising it. In this article I will talk about my expirience of handling 512K concurrent websockets using Groovy++ & Gretty. Why 512K and not 1M? This is very fair question and my initial goal was to handle exactly 1M concurrent websockets on one machine. It seems that due my lack of knowledge of tuning TCP/IP on Linux I was not able to achieve more. I had enough free CPU power and a lot of free memory but after 524285 open connections (always the same number) the server stopped to accept new connections. The magical number 524285 is so close to 524288=512*1024 that I can guess (and only guess) that we deal either with some limitation of Linux setup or with something in settings of Amazon network infrastructure (where I run my tests) . So what was the experiment about? In general it was my way to estimate (or at least to have feeling) how many (virtual) hardware units do we need if we hope to handle A LOT of concurrent users. The server itself is very simple. It does the following: On HTTP request from a client it responds with text document containing Groovy script to be executed by client. It accepts and keeps websocket connections from clients and respond to every received message (just plain string) with the same string in upper case The client program (running on separate machine) request the server for a scenario and then compile and execute it. Why do we need this trick with sending script to client? Truly speaking we don't. When I started writing the application I had illusion that it will simplify deployment to many clients. In fact, it did not and I had rsync all clients with my development machine after recompilation anyway. The scenario itself is also very straight forward. Client program opens 64000 concurrent web socket connections and approximately every 25 seconds sends to the server short string (approximately 30 characters). So server need to handle around 20000 requests per second or around 600K/s traffic in and the same amount out. Someone can argue if such structure of traffic is realistic or not. I don't want to go in to deep dispute here as it simulates very well one of applications under development in my company. To emulate 512000 concurrent clients I used 8 machines and 1 machine was the server. All machine was of the same "m1.large" Amazon EC2 instances with 7.5GB memory and 2 virtual cores running Fedora 11. 2.5GB memory was used by Java heap (around 5K per connection but of course not including kernel structures) and total CPU utilization was under 30% The server is written on Groovy++ using Gretty, which is lightweight server based on brilliant Netty framework and developed as part of Groovy++ standard library. More information on both can be found at Groovy++ home Gretty is extremely lightweight and fully non-blocking event driven web server. Gretty itself is written on Groovy++ and fully utilize concurrency libabry. It is not servlet container or any other relative of JavaEE. Right now it supports only static files http requests (including modern /param1/param2 REST-like requests) web sockets (including long-polling emulation protocol for old browsers) Here is essentially the whole server code. Obviously it is statically typed Groovy++ code. GrettyServer server = [ webContexts: [ "/" : [ public: { get("/scenario") { response.text = """ .............. here is client scenario code ................... """ } websocket("/ws",[ onMessage: { msg -> socket.send(msg.toUpperCase()) }, onConnect: { socket.send("Welcome!") }, onDisconnect: { } ]) } ] ] ] server.start() I don't want to explain more than written in the code above because I really hope the code is self explaiining. I hope it was interesting. Get Gretty and Groovy++ a try and let us know what do you think. Till next time.