[
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)
