19 Mar
2009
19 Mar
'09
3:55 p.m.
Hi,
we are running XWiki 1.7.1 on Tomcat 6 with MS-SQL.
When deleting attachments, in general, everything works fine. But on some
files we get a hibernate exception. We can't figure out why this error
appers with some attachments. Here's the exception:
A problem occured while trying to service your request. Please contact the
support if this happens again.
Detailed information:
Error number 0 in 3: Exception while hibernate execute
Wrapped Exception: The database returned no natively generated identity
value
com.xpn.xwiki.XWikiException: Error number 0 in 3: Exception while hibernate
execute
Wrapped Exception: The database returned no natively generated identity
value
at
com.xpn.xwiki.store.XWikiHibernateBaseStore.execute(XWikiHibernateBaseStore.java:1052)
at
com.xpn.xwiki.store.XWikiHibernateBaseStore.executeWrite(XWikiHibernateBaseStore.java:1098)
at
com.xpn.xwiki.store.hibernate.HibernateAttachmentRecycleBinStore.saveToRecycleBin(HibernateAttachmentRecycleBinStore.java:83)
at
com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2799)
at
com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2782)
at
com.xpn.xwiki.web.DeleteAttachmentAction.action(DeleteAttachmentAction.java:72)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:135)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)
Wrapped Exception:
org.hibernate.HibernateException: The database returned no natively
generated identity value
at
org.hibernate.id.IdentifierGeneratorFactory.getGeneratedIdentity(IdentifierGeneratorFactory.java:67)
at
org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.executeAndExtract(IdentityGenerator.java:77)
at
org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:33)
at
org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2163)
at
org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2643)
at
org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:51)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
at
org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:298)
at
org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:181)
at
org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:107)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:187)
at
org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
at
org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27)
at
org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:535)
at org.hibernate.impl.SessionImpl.save(SessionImpl.java:523)
at org.hibernate.impl.SessionImpl.save(SessionImpl.java:519)
at
com.xpn.xwiki.store.hibernate.HibernateAttachmentRecycleBinStore$1.doInHibernate(HibernateAttachmentRecycleBinStore.java:87)
at
com.xpn.xwiki.store.XWikiHibernateBaseStore.execute(XWikiHibernateBaseStore.java:1046)
at
com.xpn.xwiki.store.XWikiHibernateBaseStore.executeWrite(XWikiHibernateBaseStore.java:1098)
at
com.xpn.xwiki.store.hibernate.HibernateAttachmentRecycleBinStore.saveToRecycleBin(HibernateAttachmentRecycleBinStore.java:83)
at
com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2799)
at
com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2782)
at
com.xpn.xwiki.web.DeleteAttachmentAction.action(DeleteAttachmentAction.java:72)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:135)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)
Does anybody know how we can figure out why this happens and how we can
solve this issue?
THX,
Steve
--
View this message in context:
http://n2.nabble.com/Hibernate-exception-when-trying-to-delete-attachment-t…
Sent from the XWiki- Users mailing list archive at Nabble.com.
19 Mar
19 Mar
4:19 p.m.
New subject: [xwiki-users] Hibernate exception when trying to delete attachment
Stefan Woehrer wrote:
Hi,
we are running XWiki 1.7.1 on Tomcat 6 with MS-SQL.
When deleting attachments, in general, everything works fine. But on some
files we get a hibernate exception. We can't figure out why this error
appers with some attachments. Here's the exception:
When deleting attachments, they are not completely removed, but are
placed in a "recycle bin" table. Each row in this table has an ID
column, which is a primary key.
We use Hibernate to abstract the mapping between java objects and
relational databases. This mapping is configured in an XML file, which,
if you followed the installation instructions for MS SQL, is
xwiki.mssql.hbm.xml. In this mapping file, we say that the ID should be
generated by the database using its native key generator. In theory,
everything should be fine.
We haven't detected any problems so far, so there's probably something
wrong in the configuration. Check that you followed the instructions on
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationMSSQL
Make sure that:
- you configured the right connector (should be OK since everything else
works)
- you use the right mapping file
- try to edit the mapping file and replace the generator from native to
identity (in the DeletedAttachment section)
If this doesn't solve the problem, could you specify some more details?
- what version of mssql are you using?
- what version of the connector are you using?
- is there something special about those attachments? Like longer names,
or big size?
- can the attachments be deleted if you try again?
If nothing solves the problem, and you prefer to be able to delete all
attachments than to be able to restore them, you could disable the
attachment recycle bin, by editing xwiki.cfg and specifying:
storage.attachment.recyclebin=0
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
5:51 p.m.
New subject: [xwiki-users] Hibernate exception when trying to delete attachment
2009/3/19 Stefan Woehrer <stefan_woehrer(a)yahoo.de>
com.xpn.xwiki.store.hibernate.HibernateAttachmentRecycleBinStore.saveToRecycleBin(HibernateAttachmentRecycleBinStore.java:83)
at
com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2799)
at
com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2782)
at
com.xpn.xwiki.web.DeleteAttachmentAction.action(DeleteAttachmentAction.java:72)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
I believe this is another instance of the :"can't delete oversize
attachments" issue that I saw in 1.8. What happens is that past a certain
size limit ( smaller than the default setting per
/xwiki/bin/edit/XWiki/XWikiPreferences?editor=object
--> *XWiki.XWikiPreferences[0]* -> "Maximum Upload Size: 33554432" )
the full attachment gets stored (if there's RAM and/or swap to hold it all
in it's hugely-exploded-for-storage-in-java-format).
However, despite actually storing successfully, these oversize files cause
something in the sql->hibernate->java->xwiki->html layers to die; the UI
showing upload completion never appears. After that, the oversize file can't
be deleted either, because it invokes the same problem somewhere in the
sql->hibernate->java->xwiki->html layers.
There's several problems here.. first is that there needs to be a way of
incrementally uploading files without doing it all as a "batch" operation.
This could avoid the exploding-file-data problem from affecting
java/hibernate layers, however, it would require a change in the attachments
table to allow better incremental update of the uploaded data as it comes in
over the network. Second, having an attachment recycle bin may not be a very
good idea in the first place -- it forces copying of data betweeen tables,
causes extra data-copying, invoking the large-file bug (disable the
attachment recyclebin in xwiki.cfg and avoid the deletion issue entirely --
IMHO it should be so as default to avoid these bugs.).
Alternately, the entire issue could be avoided with a pluggable storage
module that allows regular files and uses the underlying filesystem directly
for storing attachments, large files, media, video, etc. Because the
attachments tables can get rather unwieldy in a database when they're
storing large files -- to the point where backup etc becomes an issue.
For more info:
Date: Mon, 9 Mar 2009 10:11:52 -0800
Subject: Re: [xwiki-users] Bug : unable to delete attached files in
virtualwikis
From: Niels Mayer <nielsmayer at gmail.com>
To: XWiki Users <users(a)xwiki.org>
Christophe --
Thanks for testing this. Your confirmation suggests I will follow your lead.
Unfortunately, I only noticed the xwiki.cfg options that control this after
i deleted them directly from the database in SQL:
Here are the xwiki.cfg settings I'm using to achieve this:
#-# Whether the document recycle bin feature is activated or not
# xwiki.recyclebin=1
#-# Whether the attachment recycle bin feature is activated or not
storage.attachment.recyclebin=0
#-# Whether the document versioning feature is activated or not
# xwiki.store.versioning=1
#-# Whether the attachment versioning feature is activated or not
xwiki.store.attachment.versioning=0
#-# Whether the attachments should also be rolled back when a document is
reverted.
xwiki.store.rollbackattachmentwithdocuments=0
It appears that xwiki.cfg setting xwiki.store.attachment.versioning.hint=void
is redundant with xwiki.store.attachment.versioning=0
Question for all: Is the latter the preferable way of turning off attachment
versionining?
Niels
http://nielsmayer.com
PS: doesn't it make sense to avoid such problems in the future and bypass
the recycle bin for deleted attachments. Alternately, some kind of heuristic
could be employed, as the default, e.g. the recylcle-bin is used to hold
deleted attachments, except when the attachments exceed a certain size, say
1Mb. In that case the user is warned of permanent deletion and can "ok" it
away.
--------------------------------------------------------------------------------
Date: Sat, 7 Mar 2009 01:47:08 -0800
Subject: Re: [xwiki-users] Bug : unable to delete attached files in virtual
wikis
From: Niels Mayer <nielsmayer at gmail.com>
To: XWiki Users <users(a)xwiki.org>
I had a similar problem, with attachments not being deletable, which also
prevented the document itself from being deleted. Unfortunately, this also
suggested an additional issue arising with attachments. If a user makes
large attachments to their user-document, e.g. XWiki.MyName then even in a
"closed" wiki that only allows users to edit their own user document, they
can cause a denial of service attack through large attachments. In other
words, even if the wiki is setup so that regular registered XWikiAllGroup
users don't have write access to any directory, just comment-access to
documents; they'll still have write access to their own XWiki.MyName
document created through registration... and that means they'll be able to
add attachments even when you think they couldn't. The "Rights"
adminstration checkbox "Prevent unregistered users from editing pages,
regardless of the page or space rights" doesn't prevent attachments from
being added to user's own pages.
Anyways, I ended up solving the blowups and OOM errors by deleting the
attachments directly in the database:
mysql> select XWA_ID,XWA_DOC_ID,XWA_FILENAME,XWA_SIZE,XWA_AUTHOR from
xwikiattachment where XWA_AUTHOR='XWiki.JG';
| XWA_ID | XWA_DOC_ID | XWA_FILENAME | XWA_SIZE | XWA_AUTHOR|
| 1185703559 | 168880978 | foo.pdf | 9817587 | XWiki.JG |
| -352107721 | 168880978 | bar.pdf | 13049680 | XWiki.JG |
| 1527849923 | 168880978 | baz.pdf | 293 | XWiki.JG |
| -2073884056 | 168880978 | frop.pdf | 5904061 | XWiki.JG |
| 1039500510 | 168880978 | schlop.pdf | 4440028 | XWiki.JG |
| 942569068 | 168880978 | plop.pdf | 14033466 | XWiki.JG |
| 1363529635 | 168880978 | schnops.pdf | 0 | XWiki.JG |
| -1054875919 | 168880978 | hops.jpg | 3081 | XWiki.JG |
8 rows in set (0.00 sec)
mysql> delete from xwikiattachment where XWA_AUTHOR='XWiki.JG';
Query OK, 8 rows affected (0.00 sec)
Someone please tell me if this is not the right way to fix such issues...
As afterthought, I realized that setting
xwiki.store.attachment.versioning.hint=3Dvoid in xwiki.cfg might prevent xwiki
from reading/diffing and attempting to version a large attachment. Doing so
could certainly make it run out of memory, and changing this option might
prevent the bug?:
#-# The attachment versioning storage. Use 'void' to disable attachment
versioning.
# xwiki.store.attachment.versioning.hint=default
Also, perhaps by not sending deleted attachments to the recycle bin, it
won't need to be copied anywhere, and therefore there'll not be any memory
to run out copying a giant attachment through java (assuming that's what
happens on delete).
#-# The attachment recycle bin storage.
# xwiki.store.attachment.recyclebin.hint=Ddefault
Niels
http://nielsmayer.com
PS: perhaps the defaults for xwiki.store.attachment.versioning.hint and
xwiki.store.attachment.recyclebin.hint need to be changed?
On Fri, Mar 6, 2009 at 2:37 AM, PERINAUD Christophe <
Christophe.PERINAUD(a)kbl-bank.com> wrote:
Hello (again)
All is ok in the main wiki but in a virtual wiki i can't delete an attach=
ed
file of a page. After the confirmation message i got
:
A problem occured while trying to service your request. Please contact th=
e
support if this happens again.
Detailed information:
Error number 0 in 3: Exception while hibernate execute
Wrapped Exception: could not get next sequence value
com.xpn.xwiki.XWikiException: Error number 0 in 3: Exception while
hibernate execute
Wrapped Exception: could not get next sequence value
at
com.xpn.xwiki.store.XWikiHibernateBaseStore.execute(XWikiHibernateBaseSto=
re.java:1052)
at
com.xpn.xwiki.store.XWikiHibernateBaseStore.executeWrite(XWikiHibernateBa=
seStore.java:1098)
at
com.xpn.xwiki.store.hibernate.HibernateAttachmentRecycleBinStore.saveToRe=
cycleBin(HibernateAttachmentRecycleBinStore.java:83)
at
com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2799)
at
com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2782)
at
com.xpn.xwiki.web.DeleteAttachmentAction.action(DeleteAttachmentAction.ja=
va:72)
at
com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
Subject: Re: [xwiki-users] Bug : unable to delete attached files in
virtualwikis
From: Niels Mayer <nielsmayer(a)gmail.com>
To: XWiki Users <users(a)xwiki.org>
Content-Type: multipart/alternative; boundary=000e0cd21476a7301d0464b391b3
--000e0cd21476a7301d0464b391b3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Christophe --
Thanks for testing this. Your confirmation suggests I will follow your lead.
Unfortunately, I only noticed the xwiki.cfg options that control this after
i deleted them directly from the database in SQL:
Here are the xwiki.cfg settings I'm using to achieve this:
#-# Whether the document recycle bin feature is activated or not
# xwiki.recyclebin=1
#-# Whether the attachment recycle bin feature is activated or not
storage.attachment.recyclebin=0
#-# Whether the document versioning feature is activated or not
# xwiki.store.versioning=1
#-# Whether the attachment versioning feature is activated or not
xwiki.store.attachment.versioning=0
#-# Whether the attachments should also be rolled back when a document is
reverted.
xwiki.store.rollbackattachmentwithdocuments=0
It appears that xwiki.cfg setting xwiki.store.attachment.versioning.hint=void
is redundant with xwiki.store.attachment.versioning=0
Question for all: Is the latter the preferable way of turning off attachment
versionining?
Niels
http://nielsmayer.com
PS: doesn't it make sense to avoid such problems in the future and bypass
the recycle bin for deleted attachments. Alternately, some kind of heuristic
could be employed, as the default, e.g. the recylcle-bin is used to hold
deleted attachments, except when the attachments exceed a certain size, say
1Mb. In that case the user is warned of permanent deletion and can "ok" it
away.
--------------------------------------------------------------------------------
Niels
http://nielsmayer.com
6:20 p.m.
SOLVED
Seems to be that "large file - bug" mentioned. With files > 5MB the problem
occures.
By disabling the recyclebin functionality for the attachment storage the
exception could be avoided.
Thank you very much,
Steve
--
View this message in context:
http://n2.nabble.com/Hibernate-exception-when-trying-to-delete-attachment-t…
Sent from the XWiki- Users mailing list archive at Nabble.com.
5713
days inactive
5713
days old
3 comments
3 participants
participants (3)
-
Niels Mayer -
Sergiu Dumitriu -
Stefan Woehrer