OK, but if so I can create my own copy of `activeJobs` and `waitingJobs`
collections.
My idea is to extend the existing JobStealingCollisionSpi strategy by
delegation. For example:
class CustomSpi extends IgniteSpiAdapter implements CollisionSpi {
private CollisionSpi delegate = new JobStealingCollisionSpi()
public void onCollision(CollisionContext ctx) {
// IMPLEMENT CUSTOM LOGIC TO ACTIVATE PENDING JOBS HERE
// then delegate to exiting strategy to handle job stealing
Collection<CollisionJobContext> myActiveJobs = // .. my copy
Collection<CollisionJobContext> myWaitJobs = // .. my copy
delegate.onCollision(new CollisionContext() {
@Override public Collection<CollisionJobContext>
activeJobs() {
return myActiveJobs;
}
@Override public Collection<CollisionJobContext>
waitingJobs() {
return myWaitJobs;
}
@Override public Collection<CollisionJobContext> heldJobs()
{
return myHeldJobs;
}
}
}
}
Does this make sense?
Cheers,
Paolo
On Thu, Jan 28, 2016 at 4:48 PM, Yakov Zhdanov <[email protected]> wrote:
> Hi Paolo!
>
> This will throw Unsupported operation exception. Moreover, what is the
> purpose of doing that. Underlying collections will be modified when you
> call methods on collision context object. Pls take a look
> at org.apache.ignite.internal.processors.job.GridJobProcessor#handleCollisions
> method to get an idea.
>
> Thanks!
>
> --Yakov
>
> 2016-01-28 18:39 GMT+03:00 Paolo Di Tommaso <[email protected]>:
>
>> Hello,
>>
>> I would create my own collision SPI chaining an already existing SPI
>> implementation.
>>
>> Is it safe to modify the content of the `activeJobs` and `waitingJobs`
>> collections of the CollistionContext and then delegate the execution to
>> another SPI instance `onCollision` method?
>>
>>
>> Cheers,
>> Paolo
>>
>>
>
