• What's the full version number?
• On what OS?
• How many hosts are in the cluster?
• How many forests on each host?
• Is automatic directory creation enabled?
As written the description of the problem doesn't quite make sense to me. How
can SVC-EXTIME "unnoticed... lead to" XDMP-DEADLOCK? Can you explain more
clearly how these two different exceptions are related? More of the stack
traces might help: don't try to pick out the most interesting parts.
Avoiding URI lock contention is mostly a matter of design. As described I
wouldn't expect two different requests to try to lock the same env-user
directory URI. If that's really what's happening then a rethink of the design
may be in order. For best performance the URIs should be designed such that
contention will be vanishingly rare. When contention is unavoidable it may help
to take the lock as early in each request as possible. Or it may be that the
problem is really elsewhere: a bug in an older release, or locking on an
ancestor directory URI, or something else.
XDMP-DEADLOCK will first appear as a Debug-level ErrorLog message, visible only
if file-log-level=debug or higher. At that stage it is relatively harmless, but
is a good early warning sign for lock contention. These messages also tell you
where the contention occurs. That's worth checking, because the lock contention
might turn out to be on an ancestor directory URI: /{env}/ or / itself. That
would happen if automatic directory creation is enabled, for example.
When a debug-level XDMP-DEADLOCK happens, the transaction aborts and tries
again. If two or more concurrent requests are hitting the same URI lock in a
cluster with plenty of hosts and cores, they may continue this cycle. So after
a large number of cycles, maybe 32 or 64, there will be an XDMP-DEADLOCK
exception. Or if the request time limit is reached before then, the exception
might be XDMP-EXTIME or SVC-EXTIME. This is why it's important to design the
URIs such that contention is almost impossible.
See what you can do with the questions I've asked, and the ideas outlined above.
-- Mike
On 18 Jul 2014, at 03:42 , Vinayagam, Ashwini (LNG-CON)
<[email protected]> wrote:
> Hi All,
>
> We are facing an issue while using xdmp:lock-for-update to implement the
> below use case. We are able to reproduce this issue only in a clustered
> environment.
>
> Use case:
> There is a limitation to be set on the number of items a user can store.
> Whenever a user tries to insert a document, before actual insertion, the user
> directory is locked using xdmp:lock-for-update and item count is checked. if
> the count does not reach the limit then the document is inserted.
>
> Lock mechanism is used as the item count needs to limited to a specified
> number even when there are concurrent insert request from an user.
> Eg. /{environment}/{userid}/{itemid}.xml
>
> Error details:
> We are getting the below exception when there are concurrent requests,
> Exception encountered - throwing
> com.marklogic.xcc.exceptions.XQueryException: SVC-EXTIME:
> xdmp:lock-for-update (user directory)-- Time limit exceeded
> If the above exception is unnoticed, it leads to this,
> Exception encountered - throwing
> com.marklogic.xcc.exceptions.XQueryException: XDMP-DEADLOCK:
> xdmp:lock-for-update(user directory) -- Deadlock detected locking ForestName
> ForestID
>
> Please let us know if we are missing anything here.
> _______________________________________________
> General mailing list
> [email protected]
> http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
