Hi,
We run artifactory on a linux server with the default Derby DB. We noticed
that it stopped working and tried to restart the tomcat server, but it does
not come up and we notice the exception following.
Does that mean that the DB is corrupted? Can we somehow connect to it
externally, find out
-Original Message
Do you still have by any chance the log and stack trace of the
original
compression failure?
If so, please attach it.
Unfortunately, I don't. When that first happened, I didn't expect it to
have any later fallout, so I didn't make it a point to preserve those
FWIW, I'm trying the compress again now, using the Artifactory UI to
initiate it. But even after clicking the Compress the Internal
Database button and answering yes to the are you sure dialog, I get
the little Artifactory spinner that says loading in my browser... but
nothing in the server logs
Do you see any increase in CPU/disk load after clicking the compress button?
For us to try and reproduce this - what version of Artifactory are you using
and with which storage type - pure derby or filesystem-derby?
Thanks,
Yoav
On Tue, Dec 7, 2010 at 8:00 PM, Phillip Rhodes
Hi Daniel,
It is unlikely that the effect of the original issue will be resolved
just by upgrading the lib.
If it doesn't work then moving to MySQL (or PostgreSQL etc.)-based
storage or to a newer version would be your best option.
Thanks,
Tomer
On 12/07/2010 06:57 PM, danieln wrote:
Hi
I found this page:
http://wiki.jfrog.org/confluence/display/RTF/Dealing+with+Broken+Index
Adding artifactory.jcr.fixConsistency=true and restarting Artifactory seemed
to have fixed my JCR repository.
So, bootup now proceeds further, but it fails with another stacktrace:
2010-12-07 18:05:30,840
