These are chat archives for nextflow-io/nextflow

14th
Dec 2018
Hugues Fontenelle
@huguesfontenelle
Dec 14 2018 10:35
OK I found why my processes are WAITING forever. Here's a minimally reproducible example:
mylist = ["a", "b"]

ch = Channel.create()
mylist.each {
    ch << it
}

process first {
    echo true
    input:
    val (s) from ch

    script:
"""
echo ${s}
"""
}
In words: where creating an empty channel then binding objects to it, the process waits for more objects. How can I "close" my channel (ie tell it there isn't any more objects) ?
micans
@micans
Dec 14 2018 11:10
ch.close()
Interesting stuff though. The close operator sends a termination signal over the channel, causing downstream processes or operators to stop. In a common usage scenario channels are closed automatically by Nextflow, so you won't need to use this operator explicitly.
@huguesfontenelle I tried your example with ch.close() and that works. Still I am curious what Paolo thinks.
Paolo Di Tommaso
@pditommaso
Dec 14 2018 11:33
Yes, exactly. Above create/close is really meant as ultima ratio to handle very specific use cases. I discourage to use it there's other approaches
micans
@micans
Dec 14 2018 11:40
It's not necessary with Channel.from(). I tried some other channels feeds with << and there it seems to be necessary.
Paolo Di Tommaso
@pditommaso
Dec 14 2018 11:42
exactly Channel.from manages the close for you
Hugues Fontenelle
@huguesfontenelle
Dec 14 2018 11:57
Thanks @micans .
And @pditommaso :)
micans
@micans
Dec 14 2018 12:06
:+1:
micans
@micans
Dec 14 2018 13:25

I got a failed job where after checking the work dir I found exit status 0. The log file says this:

Dec-14 12:21:33.795 [Task monitor] DEBUG nextflow.executor.GridTaskHandler - Failed to get exist status for process TaskHandler[jobId: 59730; id: 85; name: salmon (qanu_C); status: RUNNING; exit: -; error: -; workDir: /lustre/scratch117/cellgen/cellgeni/TIC-misc/tic-97/work-farm4b+medium/c1/911b8c39962988ddddc698ff644157 started: 1544789059177; exited: -; ] -- exitStatusReadTimeoutMillis: 270000; delta: 605736
Current queue status:
>   (null)

Content of workDir: /lustre/scratch117/cellgen/cellgeni/TIC-misc/tic-97/work-farm4b+medium/c1/911b8c39962988ddddc698ff644157
null

So, readtimeout error basically. This could be a sluggish file system; might it be related to what other people experienced?

Stephen Kelly
@stevekm
Dec 14 2018 16:53
@micans that sounds basically the same as what I have been dealing yeah

Not sure what scheduler you are using but the admins on our SLURM cluster got back to me with this:

The Problem is when many jobs are submitted at once the priority is to scheduling not acknowledgements. I have increased the Message time out from 10 seconds to 60 which will give squeue more time to respond during periods of heavy job submissions. Please let me know if you still see the issue.

so far none of my pipelines have broken after this change, though it also coincided with the changes I listed a few messages back on here for my Nextflow config.

Stephen Kelly
@stevekm
Dec 14 2018 19:13
@pditommaso what is the default value for executor.pollInterval? Not seeing it listed in the docs; https://www.nextflow.io/docs/latest/config.html#scope-executor