Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I am using tRunJob to run another job with option 'Use an independent process to run subjob' selected,
my problem is that child job is not running using the appropriate context group (Dev/Int/Prod) instead it always runs as default context group that is Dev in subjob.
Is this bug? I tried dynamic job as well & I had similar problem.
Could you please help? this is really critical for us at this point.
I would really appreciate any response on this issue.
Hi nmodi,
I have extensively used the trun component for lots of nested jobs that is triggered from one wrapper jobs for different environments and never had any issue, the only thing i would ensure every time is the context of the outer most job is pointing to the intended environment.
I have not used independent process to run sub-job, i am not sure if that is what is causing the problem...not sure why you need to use that option. I think that option is to have the subjob run on a different JVM, which is typically not impactful for a small to medium sized job loads...
will be more than happy to share any further experiences i may have in this regard...for your quick reference i am attaching two snippets from my work.
Thanks a lot for your response, yes, I have also used regular child job option to run then jobs & context data along with context group(dev/int/prod) is passed fine.
this is the issue only when I run job as 'Use an independent Process' or dynamic job.
for certain reason - we have a need to run this job as 'Use an independent Process'
@Moe , i have just made a testing and it works on v7.1.1. Make sure you have checked 'transmit the whole context' box on tRunjob.
Have you tried that with 'Use an independent Process' checkbox? I tried again & it still doesn;t work. it always picks up default context group, not the context group that was selected from parent job.
we are on 6.4 enterprise version.
The easiest alternative that i can think of is to build the job and run the job away from TOS. This approach would take away the tool dependency and will 100% solve your problem of enforcing a specific environment to the nested/embedded child jobs. Build job - gives you the option to apply the parent context group to all the underlying child jobs, so rest assured you can have the job running on the context group / environment that you are looking for.
I have tried that as well & that option requires me to build separate job for every environment which is what I dont want to do.
Great...this conversation is turning interesting.
That is my concern as well, i tried editing the .bat files to check if i can point to different environments from the same build version, but in vain, i observed that the context group is written even in the .jar files, so i don't think we have the option to choose the environment so seamlessly. This will be a big win to Talend if there is an easy way to point to different environments with just one build.
Lets wait to see if any of the experts have a different alternative to this.