[jira] [Comment Edited] (SLING-4828) JobManagerImpl job persisting doesn't check the created resource

["Tommaso Teofili (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14597332#comment-14597332 ] 

Tommaso Teofili edited comment on SLING-4828 at 6/23/15 8:23 AM:
-----------------------------------------------------------------

{quote} 

If it returns null, than we should check why this is the case and fix the implementation of ResourceHelper.getOrCreateResource

{quote}

that's right, I was thinking also about checking that Resource (which is assumed to be not null) is consistent with the passed properties (e.g. the passed properties and the {{Resource#getValueMap}} of the just created Resource should have the same k->v entries, plus the job specific ones).

bq. Do you know what exactly is going wrong?

not really, the problem I've experienced is that I saw a (binary) property being null in the serialized job and therefore the job processing, expecting that property to be there, results in failing but only on processing time (where it cannot be recovered as the job payload is not there anymore), rather than on serialization time.
If we would be able to fail fast in such cases it'd be possible to 
a) identify the root cause of the serialization problem
b) retry submitting the job

Note that the property I've seen missing is a {{Serializable}} one, so I wonder if it could be that there's an bug on the resource API implementation for such cases.


was (Author: teofili):
{quote} 

If it returns null, than we should check why this is the case and fix the implementation of ResourceHelper.getOrCreateResource

{quote}

that's right, I was thinking also about checking that Resource (which is assumed to be not null) is consistent with the passed properties (e.g. the passed properties and the {{Resource#getValueMap}} should have the same k->v entries, plus the job specific ones).

bq. Do you know what exactly is going wrong?

not really, the problem I've experienced is that I saw a (binary) property being null in the serialized job and therefore the job processing, expecting that property to be there, results in failing but only on processing time (where it cannot be recovered as the job payload is not there anymore), rather than on serialization time.
If we would be able to fail fast in such cases it'd be possible to 
a) identify the root cause of the serialization problem
b) retry submitting the job

Note that the property I've seen missing is a {{Serializable}} one, so I wonder if it could be that there's an bug on the resource API implementation for such cases.

> JobManagerImpl job persisting doesn't check the created resource 
> -----------------------------------------------------------------
>
>                 Key: SLING-4828
>                 URL: https://issues.apache.org/jira/browse/SLING-4828
>             Project: Sling
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: Event 3.6.0
>            Reporter: Tommaso Teofili
>
> {{JobManagerImpl#addJob}} persists the job to be started in {{writeJob}} however the result of {{ResourceHelper.getOrCreateResource}} is neither checked (!=null) nor used so it can be that the returned {{Resource}} is null or corrupted and therefore the job could not be persisted correctly, see https://github.com/apache/sling/blob/trunk/bundles/extensions/event/src/main/java/org/apache/sling/event/impl/jobs/JobManagerImpl.java#L846.
> E.g. I've experienced some cases where a binary property of a JCR node ends up being null but that is only noticed when the job is executed, not when it's persisted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)