On Thu, Sep 29, 2011 at 13:48, Jim <jcrossl...@gmail.com> wrote: > > The TorqueBox[1] team is toying with the idea of exposing to Clojure > the abstractions we currently expose to Ruby. We're looking for > feedback from you guys to see what you use now to solve these > problems, what you'd like to see in a possible Clojure "App Server", > and if you might actually use it.
Well, we would be seriously interested in it at Puppet Labs. At the moment we have a pile of Ruby code, and are using Clojure in some newer parts of the overall project. The move toward Clojure is motivated by the scale and especially parallel operation benefits that it brings to the table. The obvious attraction is that TorqueBox would bring an integrated layer below our Ruby and Clojure code; we would have the same services available to both, exposing coherent interfaces between the parts, and would also allow more intimacy around Java interop and cross-language direct calling. In terms of Clojure integration, comments around what we care about: > * asynchronous processing (with futures) Ideally we would want something compatible with Clojure futures, but if you offer (eg) bounded thread pools then having compatible syntax would be a win. Right now we can get away with the default unbounded pool size, but the choice would be awesome. > * scheduled jobs > * XA transactions > * companion services (daemons) Being able to bring these up in Clojure also would be awesome. > * distributed caching External memcache compatibility would be a big win here, for us right now, but isn't long term essential. > * messaging (via JMS) We currently use ActiveMQ to provide STOMP services for MCollective, and for some internal queue needs. AMQP/JMS messaging would be valuable, especially if it can interoperate with ActiveMQ, or supports easy broker clustering, but not essential. Access to configuring those things from Clojure would be valuable. On the client side we use clamq (https://github.com/sbtourist/clamq) to wrap up interactions with the queue service; having that, or something with similar abstractions, would be valuable. We especially like the model of a queue consumer as an infinite lazy sequence. In addition to those features, having a working and supported Ring adapter "free" as part of the distribution would be of great value. That is approximately the Ruby Rack feature, and means we can drop whatever front-end we want in place. I have not looked at JBossAS, but having a pleasant way to cooperate with lein project descriptions, or support an uber{war,jar} for getting our application in place, would be awesome. > Coming from a Ruby background, all of the above were pain points for > us. Do these same pain points exist for Clojure apps? Aside from futures, all of those have been, or are, pain points for us getting bootstrapped in our Clojure project. > TorqueBox also supports clustering, which allows load balancing of the > web component as well as cache distribution and horizontal scaling of > async tasks, scheduled jobs, and services. Clojure has built in async > processing and futures, but they use an in VM thread pool, correct? > How would you scale that? More or less the same way, as near as I can tell. > A common TorqueBox idiom is to leverage Ruby in the web tier and Java > in the services/data tier. Are there any Ring-based frameworks that > make Clojure more appealing than Ruby in the web tier? >From our point of view, Clothesline is an Erlang WebMachine clone and has been awesome for getting our RESTful service working nicely. It decomposes the process of correct HTTP request handling effectively. For strictly user-facing design we are mostly interested in richer client side code, so having something focused more on good API than on easy click-refresh page design makes that kind of moot. > Or does integrating a Ruby web app with a colocated Clojure service > make more sense? It should be fairly easy to loosely couple them via > messaging. We expect to be doing both of those things over the next year or so. > Speaking of which, if you are using Clojure to process data generated > by other apps/languages, how is that data communicated? Would language > agnostic messaging be useful here? We encode to JSON, which is sufficiently rich, as well as sufficiently feature poor, that it hits a good balance. We can express and document interfaces well between components around those basic structures, and that in turn makes it easy to get interoperability and third party developer support built in effectively. >From where we sit the three things that would be convenient are: 1. REST API for messaging which accepts JSON. (I see HornetQ delivers :) 2. Built in JSON encoding and decoding in the message queue wrapper. 3. Clojure multimethod-like dispatch on messages. For 3, right now we have a structure { "command": "some name here", ... }, and dispatch on that top level command key (and, possible, a version tag) to our top level handler. Being able to pass that to the container would be convenient, but hardly essential. > How do you currently run production code (web apps or otherwise)? Open question. We are leaning toward one of two strategies: One, embed Jetty in the JAR, and have a regular Java style `main` that fires it up. Two, build a WAR file and put it in a container. Probably an "uberwar", which contains all the dependencies as well as our production code. A JAR containing the Clojure source is a very convenient build artifact, if we have access to the leinengen dependency fetching, and the uberjar helps the next step along. > We'd love to open a dialog about these and other things. Any feedback > you care to share is appreciated, either here, or in #torquebox on > Freenode. Toby Crawley and I will be in Raleigh for Clojure/conj as > well, so we look forward to meeting you there! We wont be at the conference (this year), but I would be absolutely happy to carry on discussing this. Given that this is the first we have run into TorqueBox I don't expect anything much to show up in public for some months that would start discussion from our side. Daniel -- ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
