Clojurians Log v2

Sorry for the newbie question, but i got an UndertowInputStream as body and I was wondering if there is some utils that handles the draining...if not I can go through the classic Java loop with a buffer no problem ;)

@richiardiandrea: is the body text and not too large? if so, you can (slurp the-body)

Yeah I guess I can, I was just wondering how to handle partial transmissions @tcrawley

I would assume slurp would block until it could read everything from the stream

Uhm right, that is why I need a better way, maybe with a timeout...but thanks I'll try to figure something out :)

There is also the interesting ztellman/byte-streams to explore

I see that there is a StreamSourceChannel in here https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/io/UndertowInputStream.java#L45

so maybe I can get it somehow

I would like to get something that I can convert to core.async/manifold

like this: https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/io/UndertowInputStream.java#L119

oh -> http://immutant.org/documentation/2.1.5/apidoc/immutant.web.async.html

@richiardiandrea: yeah, so, if you want to do async stuff in immutant, that's the place to look :)

yes but from what I see this channel is for the response...I am digging 😄

can you state what you are trying to to? what's your use case?

I would like to parse the InputStream in a non-blocking way

do you want to parse the stream after sending the reply?

if not, you're blocking a thread anyway, unless you use something like spiral, possibly

https://github.com/dgrnbrg/spiral

and would like to say, timeout, if the InputStream is stale...

oh

I would think that undertow would time out connections for you, closing the InputStream, which will unblock whatever was waiting on it

spiral looks like my solution

Hi

Regarding immutant.scheduling, the docs say ":num-threads Specifies the number of worker threads for the scheduler’s thread pool"

is that for all scheduled jobs or just the one?

If the later, can I have several jobs share one thread pool?

@polymeris: the thread pool runs all the jobs you schedule through the scheduler instance

if you override the default :num-threads, you should pass it to every schedule call you want to use that pool

you can verify that it's scheduled on the right scheduler by looking at the return value. iirc, the scheduler instance is in that map

effectively, each scheduler (and its associated thread pool) is identified by the value of :num-threads you pass

which i concede is a little weird

not sure how to select a scheduler instance. If I just do (schedule fn :every [5 :minutes] :num-threads 5) a few times, do I get the same (default) scheduler instance each time?

yes

so I only get another scheduler instance if I select a different :num-threads value?

but if you pass :num-threads 3, that's going to give you a different one

correct

oh... I see

thanks

np

@polymeris: should be easy to verify at a repl. you should see that scheduler in the result.

yeah... i'll experiment a bit

it might be keyed by :id or :ids

yeah... i get the same

:ids {#object[org.projectodd.wunderboss.scheduling.QuartzScheduling
               0x4b54118e
               "org.projectodd.wunderboss.scheduling.QuartzScheduling@4b54118e"] ("42356efd-a72e-421b-9ece-421c5939f99f")}

the key of that map is the same, but not the value

yeah, i believe that map will grow only if you pass a different :num-threads

subsequent calls with the same :num-threads should grow the value only

can you have more than one scheduler with same pool size? not that I need it at the moment, but wondering

not via the immutant api, but you could with java interop to quartz itself