Fork me on GitHub
#immutant
<
2016-07-14
>
richiardiandrea04:07:38

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 ;)

tcrawley11:07:33

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

richiardiandrea14:07:57

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

tcrawley14:07:35

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

richiardiandrea14:07:24

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

richiardiandrea14:07:52

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

richiardiandrea16:07:46

so maybe I can get it somehow

richiardiandrea16:07:32

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

tcrawley17:07:31

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

richiardiandrea17:07:09

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

tcrawley17:07:54

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

richiardiandrea17:07:32

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

tcrawley17:07:06

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

tcrawley17:07:37

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

richiardiandrea17:07:55

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

tcrawley17:07:50

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

richiardiandrea17:07:07

spiral looks like my solution

polymeris20:07:21

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

polymeris20:07:32

is that for all scheduled jobs or just the one?

polymeris20:07:56

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

jcrossley320:07:38

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

jcrossley320:07:09

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

jcrossley320:07:43

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

jcrossley320:07:29

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

jcrossley320:07:47

which i concede is a little weird

polymeris20:07:52

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?

polymeris20:07:34

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

jcrossley320:07:39

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

jcrossley320:07:23

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

polymeris20:07:33

yeah... i'll experiment a bit

jcrossley320:07:02

it might be keyed by :id or :ids

polymeris20:07:43

yeah... i get the same

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

polymeris20:07:33

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

jcrossley320:07:55

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

jcrossley320:07:33

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

polymeris20:07:59

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

jcrossley320:07:26

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