Failure on restore in 3.2.3

THis happens both on tomcat and glassfish. the initial upgrade to 3.2.3 seemed to kill the DB so I tryied restoring. This is using an alternate data directory. Due to company policy I have no access to the default DB diredtory.

I have gone so far as to start with a clean install and a blank database which woks fine in the alternate directory. once I unpack the backup this is what I get.

Any help would be great I have spent all day on this.

I have tried two backups and both

give the following error

17 Apr 2012 21:15:19,269 INFO  [Refactoring                   ] [init servlet                                      ] Apply refactoring: jetbrains.charisma.refactoring.RefactoringRebuildUniqueIndexes
17 Apr 2012 21:15:19,331 INFO  [TransientSessionImpl          ] [init servlet                                      ] Catch exception in flush: Failed to delete, operation unsuccessful
17 Apr 2012 21:15:19,331 ERROR [ServletImpl                   ] [init servlet                                      ] Can't init servlet
jetbrains.exodus.database.impl.OperationFailureException: Failed to delete, operation unsuccessful
at jetbrains.exodus.database.impl.Table.checkStatus(
at jetbrains.exodus.database.impl.PropertiesTable.delete(
at jetbrains.exodus.database.PersistentEntityStoreImpl.clearProperties(
at jetbrains.exodus.database.PersistentEntityStoreImpl.deleteEntity(
at jetbrains.exodus.database.PersistentEntity.delete(
at com.jetbrains.teamsys.dnq.database.AbstractTransientEntity.deleteInternal(
at com.jetbrains.teamsys.dnq.database.TransientChangesTrackerImpl$
at com.jetbrains.teamsys.dnq.database.TransientSessionImpl.flush(
at com.jetbrains.teamsys.dnq.database.TransientSessionImpl.intermediateCommitReturnChanges(
at com.jetbrains.teamsys.dnq.database.TransientSessionImpl.intermediateCommit(
at jetbrains.charisma.refactoring.RefactoringRebuildUniqueIndexes.apply(
at jetbrains.charisma.refactoring.Refactoring.applyRefactoring(
at jetbrains.charisma.refactoring.Refactoring.access$000(
at jetbrains.charisma.refactoring.Refactoring$1$1.visit(
at jetbrains.charisma.refactoring.Refactoring$1$1.visit(
at jetbrains.mps.internal.collections.runtime.IVisitor.invoke(
at jetbrains.mps.internal.collections.runtime.IterableUtils.visitAll(
at jetbrains.mps.internal.collections.runtime.Sequence.visitAll(
at jetbrains.charisma.refactoring.Refactoring$1.visit(
at jetbrains.charisma.refactoring.Refactoring$1.visit(
at jetbrains.mps.internal.collections.runtime.IVisitor.invoke(
at jetbrains.mps.internal.collections.runtime.IterableUtils.visitAll(
at jetbrains.mps.internal.collections.runtime.Sequence.visitAll(
at jetbrains.charisma.refactoring.Refactoring.applyAll(
at jetbrains.charisma.main.YouTrackInit.init(
at jetbrains.charisma.main.InitWebApplicationServiceLocatorListener.onAfterInit(
at jetbrains.springframework.configuration.runtime.ServiceLocator.fireLocalAfterInit(
at jetbrains.charisma.main.ServletImpl.init(
at javax.servlet.GenericServlet.init(
at org.apache.catalina.core.StandardWrapper.initServlet(
at org.apache.catalina.core.StandardWrapper.allocate(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.core.StandardPipeline.doInvoke(
at org.apache.catalina.core.StandardPipeline.invoke(
at com.sun.enterprise.web.WebPipeline.invoke(
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.doService(
at org.apache.catalina.connector.CoyoteAdapter.service(
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(
at com.sun.grizzly.http.ProcessorTask.doProcess(
at com.sun.grizzly.http.ProcessorTask.process(
at com.sun.grizzly.http.DefaultProtocolFilter.execute(
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(
at com.sun.grizzly.DefaultProtocolChain.execute(
at com.sun.grizzly.DefaultProtocolChain.execute(
at com.sun.grizzly.http.HttpProtocolChain.execute(
at com.sun.grizzly.ProtocolChainContextTask.doCall(
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(
at com.sun.grizzly.util.AbstractThreadPool$

Comment actions Permalink

Hello Mike,

what was your previous version of YouTrack?

And what is the OS where YouTrack running?

Comment actions Permalink

The previous version was 3.0.4 and these are both running on windows server boxes

Comment actions Permalink

So I found out that the data will only open in 3.0.4. I have tried every version since and get the same error. I was wondering if using the python scripts to move from one Youtrack to another is an option and what I would lose in doing so?

We just introduced this to the rest of the dev groups in the company. I really hate to lose all this work and start the evaluation process all over again with another product.I loved the integration of IntelliJ, Team City and YouTrack. But if we can't reliably upgrade a minor version then it will be impossible to convince anyone else to use it.

Comment actions Permalink

Hello, Mike,

this Exception appeares in case that you tried to start YT 3.0.4 on DB after upgrade to 3.2.3.

Am I right?

Comment actions Permalink

I am not sure of the exact question you are asking. The situation is, I had a tomcat server go down(i thought it had 3.0.4) on it but not sure. Set up a different tomcat server and loaded 3.2.3 on it. I restored a backup to the new server.  I tried to open this with a  3.2.3 and it does not work (not sure if it "upgraded"). I reverted the war back to 3.0.4 and it woks, I tried every version and 3.0.4 is the only version it works with.

Let me summerize. I have a backup DB that works with 3.0.4 and it will not allow me to update to any other version. I am not sure what YT version was used to make the backup.

I hope this answers your question.

Thanks for your help.

Comment actions Permalink

mhilding wrote:

I tried to open this with a  3.2.3 and it does not work (not sure if it "upgraded").

"It doesn not work" - you mean at all?

Were you able to get any page of YouTrack?

We hadn't met such behaviour ever before.

If it is possible, cold you provide us your DB backUp so our developers could investigate it and provide a fix solution for you?

We have server for uploads - it is write-only, so noone external will be able to see you DB.

Comment actions Permalink


Thanks for the quick reply.

When I start YT 3.4.3 with the backup database restored I do not get any part of YT to display.

We are currently using YT 3.0.4 in production. When it is figured out what the issue is can I send you the latest production backup so it can be repaired and we can keep our downtime to a minimum? Our users were none to happy with the down time on the 17th. Funny how quickly people become attached to a good peice of software.

separate issue:

To muddy the waters even more I will send you two backups one from 4/17 and one from 4/15. The reason i am sending you two is that the 4/17 backup reports an error when it is uncompressed. It still opens only in 3.0.4 and it appears all the data is there.  The 4/15 backup has no error when uncompressing but still only opens in 3.0.4.

Thanks for looking into this for me.



Please sign in to leave a comment.