These are chat archives for nextflow-io/nextflow

18th
Dec 2014
Paolo Di Tommaso
@pditommaso
Dec 18 2014 08:20
@andrewcstewart Good, you replied yourself ;)
Paolo Di Tommaso
@pditommaso
Dec 18 2014 08:27
@andrewcstewart Regarding the pipeline hang, the most common cause is a misuse of operator methods. Yes the subscribe could be the reason if you use it to send the emitted items to another channel.
@andrewcstewart Can you share the subscribe fragment, so I can understand better if it may be the problem ?
Paolo Di Tommaso
@pditommaso
Dec 18 2014 08:32
@andrewcstewart Anyway my suggestion is to have always a small dataset that you can use to develop and test the pipeline. This is the best way to replicate this kind of problem.
@andrewcstewart Lastly, considered to use the Nextflow google group, strangely I'm receiving Gitter notification of unread messages, with a hude delay.
ops.. hude = huge
Andrew Stewart
@andrewcstewart
Dec 18 2014 17:18
sure
the last channel is "set val(fastq), file('*.zip') into reports"
and then I have a subscribe with "reports.subscribe { println it }"
Ill try taking it out as a test
Paolo Di Tommaso
@pditommaso
Dec 18 2014 18:35
this looks OK
that problem can arise if have two (or more) processes/operators reading from the same channel
anyway if you manage to isolate the problem with a test case would allow me to help you much more
Andrew Stewart
@andrewcstewart
Dec 18 2014 18:47
Its def the subscribe
I imagine its stuck listening on the reports channel
I dont necessarily need it there, it was just a nice feature that piggy backed onto the example code I used as a template for my pipeline
(until I understand operators better)