Slacker Cluster

Cluster support is one of the big thing in slacker 0.6.x. Cluster enables high-availability and load balancing on slacker client and server.

Slacker cluster has a centralized registry, a zookeeper node, stores information of all the namespaces and servers instances in the cluster. Once a client declared remote functions, by calling `defn-remote` or `use-remote`, it reads all available servers offering that namespace from the registry and create connection to each of them. We the user issues a request, the client randomly pick up a connection from them. So the load is eventually distributed to every instance of slacker servers. And thanks to zookeeper’s notification feature, the client watches certain znode. It will be notified when 1. a connected server goes offline 2. a new server serving required namespace added into the cluster. Thus you don’t have to change client code or restart client when server changes.

To start a slacker server and add it to a cluster, you have to provide cluster information using the new :cluster option:

(start-slacker-server (the-ns 'slacker.example.api)
                      2104
                      :cluster {:zk "127.0.0.1:2181"
                                :name "example-cluster"})
  • :zk is the address of zookeeper node
  • :name is a znode qualified string, to identify the cluster

On the client side, it’s important to use APIs from `slacker.client.cluster` instead of `slacker.client`:

(use 'slacker.client.cluster)
;; arguments: cluster-name, zookeeper address
(def sc (clustered-slackerc "example-cluster" "127.0.0.1:2181"))
(use-remote 'sc 'slacker.example.api)

;; call the function from a random server
(timestamp)

If all servers provide ‘slacker.example.api go offline, slacker client will raise a “not-found” exception.

Slacker cluster is also designed with simple and clean in mind. You don’t have to change you business code to make it remote or cluster. Everything is transparent and non-invasive. Enjoy it.

Slacker 0.6: Exposing multiple namespaces

After 98 commits in about one month, I’m glad to announce [slacker "0.6.1"].

One thing in slacker 0.6.x is you can expose multiple namespaces from a single server.

Suppose you have two namespaces `redday.stats` and `redday.api`, both contains functions you want to expose.

  (start-slacker-server [(the-ns 'redday.stats)
                         (the-ns 'redday.api)]
                        6565)

This will expose `redday.stats` and `redday.api` on port 6565.

On the client side, we have a new `use-remote` behaviors like clojure’s use. Instead of local one, it imports functions from a remote namespace to your current namespace.

(use 'slacker.client)
;; create a slacker client
(def scp (slackerc "127.0.0.1:6565"))

(use-remote 'scp 'redday.api) ;; caution, use the symbol of 'scp here
(use-remote 'scp 'redday.stats)

;;top-titles is a function in redday.api
;;now you can use the remote function transparently
(top-titles "programming")

;;check function metadata you can find more slacker properties
(meta top-titles)

If you need to configure callback to a particular function, you can still use `defn-remote` to specify the callback function. In slacker 0.6.0, a `:remote-ns` is required when you define such a remote function.

(defn-remote top-titles :remote-ns "redday.api" :callback #(println %))

The complete code example (both server and client) can be found here.

In next post, I will explain another big new feature of 0.6.x, cluster support.

ClojureDocs Android App

利用春节的假期写了一个Android应用,可以在ClojureDocs.org上搜索clojure API,浏览文档、源代码和社区贡献的代码实例。ClojureDocs在我学习Clojure的过程中起了很大的作用,所以我想这个网站应该对很多人有用。

无暇去学习Android平台上繁琐的知识,不过好在有Phonegap这样的框架,可以把网页应用转化为本地应用,并且提供访问本地设备的API。通过Phonegap开发的程序还可以直接移植到iphone平台上。ClojureDocs Android就是运行在Phonegap中。

首页:

搜索界面

API函数界面

你可以从github获得代码和签名过的apk:https://github.com/sunng87/clojuredocs-android

Known Issue,phonegap程序在屏幕旋转时会崩溃,已经在2.3和3.2上重现,目前还不清楚具体的原因。(Edit 20120127: Fixed in 1.0.4)

欢迎任何的pull request。

Clojure on CloudFoundry

In this article, I will show you how to develop and deploy clojure web application on CloudFoundry. As you may know, CloudFoundry is an opensource PaaS backed by VMWare. Java, Ruby and Nodejs are officially supported. As a JVM language, clojure is born to be also available on this platform, although it’s not listed.

CloudFoundry accepts a .war file for Java web application deployment. So you don’t need the ring-jetty-adaptor and a procfile as heroku requires. To help your development and deployment, I strongly recommend the lein-ring plugin:

  :dev-dependencies [[lein-ring "0.5.4"]]

CloudFoundry provides backend services like mysql, redis, mongodb and more. The connection information are stored as environment variables. Here you can find a subset of them.

Take mongodb as example, connection information (host, port, username and password) are encoded as JSON, stored in environment variables. You can get them with this function:

(defn mongo-config [key]
  (if-let [services (System/getenv "VCAP_SERVICES")]
    (let [services-dict (json/read-json services false)]
      (-> services-dict
        (get "mongodb-1.8")
        first
        (get "credentials")
        (get key)))))

In the server bootstrap function, create the mongodb connection:

(defn app-init []
  (def db-conn (make-connection
                 (or (mongo-config "db") "lazypress")
                   :host (or (mongo-config "hostname") "localhost")
                   :port (or (mongo-config "port") 27017)))
  (when-not (nil? (mongo-config "username"))
    (authenticate db-conn
      (mongo-config "username")
      (mongo-config "password")))

By adding check for nil, local databased is also supported. This is pretty convenience for local development. These environment variables are consistent on all cloudfoundry application, so it’s possible to deploy the application on multiple accounts without any changes.

Then you can add your web stuff just like standard clojure web development. (If you are using compojure, place your static files under resource/public.)

Finally, package it. (Suppose your application is named as “lazypress”)

lein ring uberwar lazypress.war

Use the vmc tool to deploy it:

vmc update lazypress

For more usage about the vmc tool, you can read this article.

So you have finished deploying your clojure web application to cloudfoundry.

Backed by spring and vmware, cloudfoundry is more Java-friendly than other PaaS like heroku. You don’t have to start a Java process by yourself (“lein run” isn’t a graceful way to start your app in product environment). And you don’t have to worry about your web container settings (configure jetty with limited options via ring-jetty-adaptor). All you have to do is package the application as a portable war file, which you can deploy to tomcat, glassfish, and also cloudfoundry. The vmc tool could detect you war file and handle it correctly.

slacker 0.4.0 released

Slacker 0.4.0 has been released to clojars.org . There are new features and breaking changes in this release.

Breaking Changes

  • New maven coordinator: [slacker "0.4.0"] (groupId renamed to slakcer)
  • defremote renamed to defn-remote
  • SlackerException removed. slacker now uses slingshot for exception handling
  • Rename :async option of defn-remote to :async?

What’s new in 0.4.0

  • Add new serialization type :clj
  • New interceptors: execution time stats, args logger, slow watch dog
  • New HTTP interface
  • Server inspect commands
  • utility functions/macros defn-remote-all, defn-remote-batch and meta-remote

Get more information on github.