Print

[brian]

Can a JVM which did not submit a job attach a JobListener to a currently running job and get JobEvent callbacks? I'm thinking of cases where I'd like the client who submits the job to die immediately, and have another process do the monitoring.
Thanks.

[lolo]

Hello,

Can a JVM which did not submit a job attach a JobListener  to a currently running job [...]?

Unfortunately, this is not possible. There are  two ways to monitor a job that was not submitted locally:

• using the related management APIs
• or, more conveniently, with the job monitoring API which provides a more consistent object model and event listener mechanism. This is the API used by the administration console to monitor jobs

Sincerely,
-Laurent

[brian]

Hi Laurent,

Ok, I think there is a feature request brewing here! My clients who submit jobs are unreliable. They often run on machines which are automatically rebooted over the weekend. A client bouncing should not mean that the task results are no longer available to be processed!

One option would be allowing re-attach, where a client process can bounce and re-attach to running jobs with a JobListener, fetching their task results. This sounds a bit complicated to get right.

I think a better option would be providing support for a job to be submitted with a JobListener, allowing client to submit the job+listener then exit. The highly available JPPF driver would ensure the listener is invoked for each task, just as it does for clients which don't detach. Your JobDependencies sample exhibits somewhat similar behavior, but (a) it's not based on builtin API and (b) results are not provided to downstream jobs. So it doesn't quite work. Letting the client submit a listener would be great. It reminds me of MapReduce, where this submitted listener is like a reducer, so I guess could fit under issue JPPF-7.

[brian]

Hi,
Have you had a chance to consider these ideas?
Thanks.

[brian]

Hi,
Have you had a chance to consider these ideas?
Thanks.

[lolo]

Hello,

Can you please take a look at this feature request, and comment if you have any feedback: JPPF-480 Jobs persistence in the driver. I believe this covers the case of a client re-attaching to a job.

As to a job listener/callback that a driver can call, I willl investigate as to a possible ad-hoc solution that can be implemented as a sample in the 5.2 branch, then as a built-in API in 6.0. As far as I can see, it is not doable as a built-in feature in 5.2 without breaking compatibility.

-Laurent

[lolo]

Hello,

I have created an enhancement request for a job listener available to the driver, which should satisfy your requirements: JPPF-494 Extend the driver's JobTaskListener facility. Would you mind taking a peek and let us know if this would work for you?

This approach is not very disruptive (it will only break exisiting implementation of this plugin and its just a matter of adding an empty method to the listener), so it can be delivered in the next maintenance release v5.2.6.

Thanks,
-Laurent

[brian]

Thanks for your feedback. I think 494 would solve my problem. With it, I would not need 480 too, clients would fire and forget, letting jppf exec the "continuation".

[lolo]

Great! You're invited to give it a try, as it was released earlier this week in v5.2.6.

-Laurent