Thanks for noting this. I have not yet encountered this error, but it
definitely would be worth trying to find a way to reliably reproduce it
From the error stacktrace you linked to, it looks like the problem
originates in the UploadWithEmbargoStep of the submission process (at
least in this example). If you are able to recreate this error again,
it might be interesting to see what is similar between each of the
stacktraces. Is it a single submission step to blame? Does the error
occur more randomly (in different submission steps)?
Essentially if we can find a similarity between these stacktraces or a
way to reliably reproduce the error, it would help us in determining
whether this is only encountered with particular configurations/setups,
and/or what the root cause may be.
You are welcome to create a ticket for investigating this issue, as that
may be a better place to add notes should anyone encounter this issue.
If we find it to be a non-issue, we can always close the ticket.
Thanks, and please do let us know if you find ways to reproduce or
similarities between the error stacktraces.
On 9/22/2016 5:28 AM, Ilja Sidoroff wrote:
I've been testing the latest git master (upcoming DS 6), and since pulling the
latest changes on Tuesday, I've encountered errors like:
ERROR: prepared statement "S_29" does not exist
(a paste for the full stack trace: http://pastebin.com/2mLKNNHD)
(where "S_29" varies). The errors seem to happen when I use workflow functionality
and try to submit something, or directly try to submit something to a collection. When the
error state is on, I cannot start new submissions, upload bitstreams from the workflow, or
upload bitstreams from administration->edit item - and possibly more. I don't know
exactly what are the conditions for reproducing this nor I know how to recover from the
state. I managed recovery once by restarting postgres, but in general it doesn't seem to
I first encountered this on Tuesday and asked help on irc. Helix84 did some
googling and one reason this might happen, is some sort of concurrency problem,
where the original PSTMT gets deleted/flushed out and is not available when
resumed (unfortunately I don't have the reference or the irc log).
My environment is: Ubuntu 16.04, Java 1.8, Jetty 9, PostgreSQL 9.5. I'll
continue examining the issue to determine if it is just something in my own
environment or a genuine bug.
University of Eastern Finland
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org
You received this message because you are subscribed to the Google Groups "DSpace
Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.