aleph 0.2.1-rc1 and 0.3.0-alpha1 both released

[ztellman]

I've retagged 0.2.1-beta2 as rc1.  It appears to be quite stable, a formal release should be forthcoming soon.  It will be compatible with Clojure 1.2.1, 1.3.0, and 1.4.0.

The more interesting release is 0.3.0-alpha1.  The is a rewrite on top of the new Lamina, and in addition to being much simpler, it's now ~5x faster across all benchmarks.  On the ever-important "Hello World" HTTP benchmark, it's about 75% as fast as Aloha [1].  I expect that for the vast majority of people using Aleph, this should be a drop-in replacement for earlier versions.  If anyone discovers problems or incompatibilities, please let me know.

Zach

[1] https://github.com/ztellman/aloha

[Daniel Renfer]

I've swapped out my 0.2.1-beta2 for 0.3.0-alpha1 and this is what I get:

Caused by: java.lang.RuntimeException: Unable to resolve symbol:
defprotocol-once in this context, compiling:(lamina/core/utils.clj:16)
at clojure.lang.Compiler.analyze(Compiler.java:6235)
at clojure.lang.Compiler.analyze(Compiler.java:6177)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3452)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6411)
at clojure.lang.Compiler.analyze(Compiler.java:6216)
at clojure.lang.Compiler.analyze(Compiler.java:6177)
at clojure.lang.Compiler.eval(Compiler.java:6469)
at clojure.lang.Compiler.load(Compiler.java:6902)
at clojure.lang.RT.loadResourceScript(RT.java:357)
at clojure.lang.RT.loadResourceScript(RT.java:348)
at clojure.lang.RT.load(RT.java:427)
at clojure.lang.RT.load(RT.java:398)
at clojure.core$load$fn__4610.invoke(core.clj:5386)
at clojure.core$load.doInvoke(core.clj:5385)
at clojure.lang.RestFn.invoke(RestFn.java:408)



Looks like it pulled in Lamina 0.4.1-beta2

[Daniel Renfer]

ignore me. Lamina was being specified somewhere else and it was
overriding what I had. I just had to change the places I used
lamina.core/task and it's working fine.

[Zach Tellman]

That's the right version of Lamina. Clear out
~/.m2/repository/potemkin and try again, if you dont mind.

Zach

[Brandon Harvey]

On Saturday, April 28, 2012 11:42:12 AM UTC-7, ztellman wrote:

That's the right version of Lamina.  Clear out
~/.m2/repository/potemkin and try again, if you dont mind.

For my project, I deleted the dir you mentioned, and my deps directory, and then did lein deps.   Here's a snippet of crashing code -- I only included a snippet because execution doesn't get as far as the "...".  

(defn main-tcp-handler [ch info]

  (println "!!!! new client:" info)

  (lamina.core/run-pipeline

    (lamina.core/read-channel ch)

    (fn [[preamble & etc]]

      (println "got preamble")

       ...

(defn start-jam-session

  ([port]

    (aleph.tcp/start-tcp-server #'main-tcp-handler {:port port})))

Here's the stack trace -- still learning how to read these things. I don't think the relevant use of "nth" is in my code.  I've tried with Clojure 1.3 and 1.4.

jamsession.core=> !!!! new client: {:address 127.0.0.1}

Apr 30, 2012 10:21:51 PM sun.reflect.NativeMethodAccessorImpl invoke0

SEVERE: Unhandled exception in pipeline at jamsession.core, line 280

java.lang.UnsupportedOperationException: nth not supported on this type: BigEndianHeapChannelBuffer

at clojure.lang.RT.nthFrom(RT.java:835)

at clojure.lang.RT.nth(RT.java:785)

at jamsession.core$main_tcp_handler$reify__10166$fn__10169.invoke(core.clj:280)

at jamsession.core$main_tcp_handler$reify__10166.run(core.clj:280)

at lamina.core.pipeline$resume_pipeline.invoke(pipeline.clj:58)

at lamina.core.pipeline$subscribe$fn__3881.invoke(pipeline.clj:113)

at lamina.core.result.ResultChannel.success_BANG_(result.clj:252)

at lamina.core.queue.EventQueue.enqueue(queue.clj:305)

at lamina.core.graph.node.Node.propagate(node.clj:260)

at lamina.core.channel.SplicedChannel.enqueue(channel.clj:101)

at lamina.core$enqueue.invoke(core.clj:101)

at aleph.netty.server$server_message_handler$reify__9838.handleUpstream(server.clj:108)

at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)

at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:792)

at aleph.netty.core$upstream_traffic_handler$reify__9614.handleUpstream(core.clj:160)

at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)

at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:792)

at aleph.netty.core$connection_handler$reify__9608.handleUpstream(core.clj:150)

at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)

at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)

at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:94)

at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:372)

at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:246)

at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:38)

at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)

at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at aleph.netty.core$cached_thread_executor$reify__9574$fn__9575.invoke(core.clj:67)

at clojure.lang.AFn.run(AFn.java:24)

at java.lang.Thread.run(Thread.java:680)

 

[Zach Tellman]

You're destructuring the bytes coming in, which is implicitly calling
'nth' on the ChannelBuffer. Did you mean for the data to already be
decoded? Maybe start-tcp-server is missing a :frame argument.

Zach

[Brandon Harvey]

It's true I don't use gloss at all and there is no :frame argument -- I do completely custom handling of the binary blobs I receive.  Is that still a viable use case?  If so, what sort of argument could I give to start-tcp-server to make it happy?

[Zach Tellman]

Oh, okay, in that case just (map* aleph.formats/bytes->byte-buffers
ch) and do a read-channel from that. I had assumed no one was relying
on the fact that the output from tcp-server was a list of ByteBuffers,
only that it could be modified using aleph.formats. Apparently I was
mistaken. I'm going to leave this as it is, but I apologize for the
confusion.

Zach

[thenwithexpandedwingshesteershisflight]

I just moved to 0.3.0-alpha2 from 0.2.1. My application serves a single webpage from which everything is done via websockets (using Google Closure's wrapper for Firefox's or Chrome's websocket via CLojurescript) - everything works beautifully with 0.2.1, but with 0.3.0-alpha2, after the first websocket connection no further connections are handled (the browser cannot send anything via a websocket, nor can the server send anything back), my server app slows down (e.g. just doing (+ 1 2) takes a few seconds) and if I try to refresh the page the servertakes ages to respond - it is clearly doing something, but I can't tell what. So, the first websocket communication works: the browser successfully creates a websocket, sends a message (some JSON) which is correctly handled by the server, the server responds, the client receives the response (some JSON), then after that no response and slowdown.

[thenwithexpandedwingshesteershisflight]

...ok I just tried sending a message on a connected client's channel on the server side via the repl, and now all the previous messages sent on it came through and the webclient was updated etc, but it's slow...

[thenwithexpandedwingshesteershisflight]

...yes it's all working now, but the flow of messages is very unpredictable and unresponsive. It used to be very responsive, now things get stuck, then catch up.

[Zach Tellman]

Very odd. Can you do a jstack thread dump while things are hanging?

Zach

[thenwithexpandedwingshesteershisflight]

On Thursday, June 7, 2012 12:00:16 PM UTC+10, ztellman wrote:

Very odd.  Can you do a jstack thread dump while things are hanging?

here
(what a handy thing to do! I found some reflection going on that was not reported by *warn-on-reflection*)

[thenwithexpandedwingshesteershisflight]

ok thanks problem solved. I was sending a message internally over a channel which contained an infinite sequence!

[Zach Tellman]

Was this infinite sequence causing different behavior in 0.3.0 and 0.2.1?

Zach

[thenwithexpandedwingshesteershisflight]

On Friday, June 8, 2012 7:28:37 AM UTC+10, ztellman wrote:

Was this infinite sequence causing different behavior in 0.3.0 and 0.2.1?

yes. I didn't know it was there when I was using 0.2.1-SNAPSHOT, I only found it when I switched to 0.3.0 and I just did a test switching back and forth to check and it's definitely there. I am enqueueing a hashmap with infinite seqs in some of its values and that did work in 0.2.1-SNAPSHOT (not a good idea though!)