Bugzilla – Full Text Bug Listing
| Summary: | Problem connecting to the database | ||
|---|---|---|---|
| Product: | [Technology] Jubula | Reporter: | Richard Skoog <richard.skoog> |
| Component: | Core | Assignee: | Project Inbox <jubula.core-inbox> |
| Status: | CLOSED INVALID | QA Contact: | Oliver Goetz <Oliver.Goetz> |
| Severity: | critical | ||
| Priority: | P3 | CC: | Achim.Loerke, alexandra.schladebeck, denis.roy, zeb.ford-reitz |
| Version: | 1.1.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Richard Skoog
Created attachment 207647 [details]
Attaching the database as requested. The database is extremely large but hopefully it's possible to upload anyway.
Created attachment 207648 [details]
Installation details.
The attachment seems to have failed, probably because it is indeed very large. The resetting of the Windows password may have had some effect on the embedded database - if permissions have changed or been lost, then this would certainly affect the file-based database in your home directory. Another possibility is if firewall settings have changed. The other possibility is that the size of the database caused quota problems in your home directory, or that the embedded database itself has reached its boundaries. We don't recommend using the embedded database for productive use: - http://help.eclipse.org/indigo/topic/org.eclipse.jubula.client.ua.help/html/manual/node205.html - Chapter 7.1 in the installation manual You could try copying the database file to another location, one where you are sure that you have all permissions, no firewall problems etc and add a new database configuration in the preferences to point to this place. That may help you to access the database again. (In reply to comment #3) > The attachment seems to have failed, probably because it is indeed very large. > > The resetting of the Windows password may have had some effect on the embedded > database - if permissions have changed or been lost, then this would certainly > affect the file-based database in your home directory. Another possibility is > if firewall settings have changed. > > The other possibility is that the size of the database caused quota problems in > your home directory, or that the embedded database itself has reached its > boundaries. We don't recommend using the embedded database for productive use: > > - > http://help.eclipse.org/indigo/topic/org.eclipse.jubula.client.ua.help/html/manual/node205.html > > - Chapter 7.1 in the installation manual > > You could try copying the database file to another location, one where you are > sure that you have all permissions, no firewall problems etc and add a new > database configuration in the preferences to point to this place. That may help > you to access the database again. Hi, I copied the database (the database directory including the three database files embedded.data.db, embedded.index.db and embedded.trace.db) to a new location and created a new database configuration pointing to that location and now the database loads successfully, but... the database doesn't include my projects with my test cases. It only includes the standard modules: unbound_modules_concrete unbound_modules_html, unbound_modules_rcp and unbound_modules_swt. Are my projects stored anywhere else or where did they go? This is the console output: Connection to Database successful. Importing projects... Reading projects... Reading project file /resources/library/unbound_modules_html_5.2.xml. Reading project file /resources/library/unbound_modules_rcp_5.2.xml. Reading project file /resources/library/unbound_modules_concrete_5.2.xml. Reading project file /resources/library/unbound_modules_swt_5.2.xml. Project "unbound_modules_swt" in version 5.2 requires the following project(s): - project "unbound_modules_concrete" in version 5.2 Finished reading projects. Importing unbound_modules_html_5.2... Finished importing unbound_modules_html_5.2. Importing unbound_modules_rcp_5.2... Finished importing unbound_modules_rcp_5.2. Importing unbound_modules_concrete_5.2... Finished importing unbound_modules_concrete_5.2. Importing unbound_modules_swt_5.2... Finished importing unbound_modules_swt_5.2. Finished importing projects. Connection to Database successful. Regards Richard That probably means that you've created a completely new database instead of connecting to the existing one. If you can find the place where it's actually been created, then you may be able to see where the path needs to be changed to access the one you want. (In reply to comment #5) > That probably means that you've created a completely new database instead of > connecting to the existing one. If you can find the place where it's actually > been created, then you may be able to see where the path needs to be changed to > access the one you want. Can't really see the problem. My embedded original database is stored here: C:\Documents and Settings\rskoog\.jubula\database I copied that directory to: D:\Jubula\database I then created a new database connection in the Jubula preferences menu. The new configuration is pointing to D:\Jubula\database See attachments Jubula_Database_1.jpg, Jubula_Database_2.jpg, Jubula_Database_3.jpg and Jubula_Database_4.jpg. Can I do it in some other way? The only strange thing I can see is that the original H2 embedded database connection has a location of ~/.jubula/database/embedded That embedded directory doesn't exist! See attachment Jubula_Database_1.jpg. Regards Richard Created attachment 207731 [details]
Database connection 1
Created attachment 207732 [details]
Database connection 2
Created attachment 207733 [details]
Database connection 3
Created attachment 207734 [details]
Database connection 4
The fact that the "embedded" directory doesn't exist is not a problem. It's likely the reason that the database gets created again, as your description of a nearly empty database implies. The "embedded" directory should now exist and contain the newly created database (embedded.data.db, etc.). Because the "embedded" directory was not initially present, and because I can see a 5.1.00156 directory in one of your screenshots, I'm assuming that you were previously using an earlier version of Jubula and/or GUIdancer. This may be causing problems if you did not migrate your Projects/database when upgrading to the new Jubula version...I can't recall at the moment whether the most recent version required database migration. If you know when the upgrade occurred, that may help to narrow down the possible causes of the error. (In reply to comment #11) > The fact that the "embedded" directory doesn't exist is not a problem. It's > likely the reason that the database gets created again, as your description of > a nearly empty database implies. The "embedded" directory should now exist and > contain the newly created database (embedded.data.db, etc.). > > Because the "embedded" directory was not initially present, and because I can > see a 5.1.00156 directory in one of your screenshots, I'm assuming that you > were previously using an earlier version of Jubula and/or GUIdancer. This may > be causing problems if you did not migrate your Projects/database when > upgrading to the new Jubula version...I can't recall at the moment whether the > most recent version required database migration. If you know when the upgrade > occurred, that may help to narrow down the possible causes of the error. Everything has been working fine after the upgrade I did a couple of weeks ago. That's probably not the problem. The scenario that caused this mess is certainly the reset of my windows password made by the IS/IT department. I therefor moved the database like you suggested to a new location just like I described above. The question now is if I did the move correctly? After the move the connection to the database is OK according to Jubula but my project isn't there anymore just the default projects. Regards Richard If you have a look at the directory ${HOME}/.jubula/database/embedded, it should exist now, whereas it did not exist in your screenshot https://bugs.eclipse.org/bugs/attachment.cgi?id=207732. This would mean that, when connecting to the database, you are using the "Default Embedded (H2)" connection rather than the "Skoogs Jubula Database" connection that you defined. Using "Skoogs Jubula Database" instead should connect you to your copied database.
Are you prompted to select a database connection when connecting to the database (for example, when opening a Project for the first time after starting Jubula, or after a "Select Database...")? If not, then we need to address why that is not happening, because multiple available database connections should result in such a prompt.
If prompted, which database connection do you select? If you select "Skoogs Jubula Database", and Jubula connects to the default database (that does not contain your Projects) despite that, then we need to address why Jubula insists on using the default connection.
(In reply to comment #13) > If you have a look at the directory ${HOME}/.jubula/database/embedded, it > should exist now, whereas it did not exist in your screenshot > https://bugs.eclipse.org/bugs/attachment.cgi?id=207732. This would mean that, > when connecting to the database, you are using the "Default Embedded (H2)" > connection rather than the "Skoogs Jubula Database" connection that you > defined. Using "Skoogs Jubula Database" instead should connect you to your > copied database. > > Are you prompted to select a database connection when connecting to the > database (for example, when opening a Project for the first time after starting > Jubula, or after a "Select Database...")? If not, then we need to address why > that is not happening, because multiple available database connections should > result in such a prompt. > > If prompted, which database connection do you select? If you select "Skoogs > Jubula Database", and Jubula connects to the default database (that does not > contain your Projects) despite that, then we need to address why Jubula insists > on using the default connection. The embedded directory (${HOME}/.jubula/database/embedded) still doesn't exist and I can't connect to the "Default Embedded (H2)" database. This connection was destroyed when resetting my windows password. I however successfully connect to my copied database "Skoogs Jubula Database" (I'm prompted to choose database when opening a project), but "Skoogs Jubula Database" doesn't include my own projects only the default projects. This is the problem right now. My own projects (modules) and constructed test cases are gone and I was hoping to see them again after copying the database to a new location on the harddrive, but unfortunately I only see the default projects with the standard modules: unbound_modules_concrete unbound_modules_html, unbound_modules_rcp and unbound_modules_swt. Regards Richard Ok, I can at least see the reason for the newly created database. The "Location" field for configuring a H2 database connection needs to contain the path to the database files, including base filename. Changing the Location to "D:\Jubula\database\embedded" should point Jubula to right database location (note the additional "embedded" due to the fact that the database files are named "embedded.data.db", "embedded.index.db, etc."). (In reply to comment #15) > Ok, I can at least see the reason for the newly created database. The > "Location" field for configuring a H2 database connection needs to contain the > path to the database files, including base filename. > > Changing the Location to "D:\Jubula\database\embedded" should point Jubula to > right database location (note the additional "embedded" due to the fact that > the database files are named "embedded.data.db", "embedded.index.db, etc."). Adding "embedded" to the database location path so that it's now "D:\Jubula\database\embedded" makes the connection fail when I try to open the database. (In reply to comment #16) > (In reply to comment #15) > > Ok, I can at least see the reason for the newly created database. The > > "Location" field for configuring a H2 database connection needs to contain the > > path to the database files, including base filename. > > > > Changing the Location to "D:\Jubula\database\embedded" should point Jubula to > > right database location (note the additional "embedded" due to the fact that > > the database files are named "embedded.data.db", "embedded.index.db, etc."). > > Adding "embedded" to the database location path so that it's now > "D:\Jubula\database\embedded" makes the connection fail when I try to open the > database. The client log for the database connection attempt looks like this: 2011-12-02 07:51:47.939 [Worker-5] ERROR o.e.j.c.core.persistence.Persistor - no or wrong username or password javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.DatabaseException Internal Exception: java.sql.SQLException: No suitable driver found for jdbc:h2:D:\Jubula\database\embedded;MVCC=TRUE;AUTO_SERVER=TRUE;DB_CLOSE_ON_EXIT=FALSE Error Code: 0 at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:422) ~[org.eclipse.persistence.jpa_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:185) ~[org.eclipse.persistence.jpa_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:242) ~[org.eclipse.persistence.jpa_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:230) ~[org.eclipse.persistence.jpa_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] at org.eclipse.jubula.client.core.persistence.Persistor.buildSessionFactoryWithLoginData(Persistor.java:281) [org.eclipse.jubula.client.core_1.1.0.201109140653.jar:na] at org.eclipse.jubula.client.core.persistence.Persistor.<init>(Persistor.java:156) [org.eclipse.jubula.client.core_1.1.0.201109140653.jar:na] at org.eclipse.jubula.client.core.persistence.Persistor.instance(Persistor.java:596) [org.eclipse.jubula.client.core_1.1.0.201109140653.jar:na] at org.eclipse.jubula.client.core.persistence.Persistor.access$4(Persistor.java:591) [org.eclipse.jubula.client.core_1.1.0.201109140653.jar:na] at org.eclipse.jubula.client.core.persistence.Persistor$2.run(Persistor.java:192) [org.eclipse.jubula.client.core_1.1.0.201109140653.jar:na] at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) [org.eclipse.core.jobs_3.5.1.R36x_v20100824.jar:na] Caused by: org.eclipse.persistence.exceptions.DatabaseException: Internal Exception: java.sql.SQLException: No suitable driver found for jdbc:h2:D:\Jubula\database\embedded;MVCC=TRUE;AUTO_SERVER=TRUE;DB_CLOSE_ON_EXIT=FALSE Error Code: 0 at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:324) ~[org.eclipse.persistence.core_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:319) ~[org.eclipse.persistence.core_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.sessions.DefaultConnector.connect(DefaultConnector.java:138) ~[org.eclipse.persistence.core_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162) ~[org.eclipse.persistence.core_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:592) ~[org.eclipse.persistence.core_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:233) ~[org.eclipse.persistence.jpa_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:394) ~[org.eclipse.persistence.jpa_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] ... 9 common frames omitted Caused by: java.sql.SQLException: No suitable driver found for jdbc:h2:D:\Jubula\database\embedded;MVCC=TRUE;AUTO_SERVER=TRUE;DB_CLOSE_ON_EXIT=FALSE at java.sql.DriverManager.getConnection(Unknown Source) ~[na:1.6.0_18] at java.sql.DriverManager.getConnection(Unknown Source) ~[na:1.6.0_18] at org.eclipse.persistence.sessions.DefaultConnector.connect(DefaultConnector.java:98) ~[org.eclipse.persistence.core_2.2.0.v20110202-r8913.jar:2.2.0.v20110202-r8913] ... 13 common frames omitted The error message and stack trace are the same as in the original bug report, so moving the database did not seem to solve the problem. It might be worth running some diagnostics on the database, as well as trying to find a way to export the contents in a way that would permit further analysis (i.e. small enough filesize that it can be successfully uploaded and downloaded via bugzilla). Try backing up the database using H2's "Script" tool (http://www.h2database.com/html/tutorial.html#upgrade_backup_restore). This should check the integrity of the database as well as produce a more compact export of the database contents. (In reply to comment #18) > The error message and stack trace are the same as in the original bug report, > so moving the database did not seem to solve the problem. It might be worth > running some diagnostics on the database, as well as trying to find a way to > export the contents in a way that would permit further analysis (i.e. small > enough filesize that it can be successfully uploaded and downloaded via > bugzilla). > > Try backing up the database using H2's "Script" tool > (http://www.h2database.com/html/tutorial.html#upgrade_backup_restore). This > should check the integrity of the database as well as produce a more compact > export of the database contents. Not sure if I did it correctly but it didn't work and I received the following message (also see attachment Database connection 5): Unsupported database file version or invalid file header in file "Old database: C:/Documents and Settings/rskoog/.jubula/database/embedded.data.db - please convert the database to a SQL script and re-create it." Created attachment 207832 [details]
Database connection 5
It sounds like you used a more recent version of H2 to perform the Script operation than Jubula used to create the database. Jubula 1.1 uses H2 1.1.117. You should be able to find and use the JAR file directly from Jubula's "plugins" directory (the H2 jar filename should be "org.h2_1.1.117.v20091003-1000.jar"). That should resolve the "Old database" problem that you are experiencing. (In reply to comment #21) > It sounds like you used a more recent version of H2 to perform the Script > operation than Jubula used to create the database. Jubula 1.1 uses H2 1.1.117. > You should be able to find and use the JAR file directly from Jubula's > "plugins" directory (the H2 jar filename should be > "org.h2_1.1.117.v20091003-1000.jar"). That should resolve the "Old database" > problem that you are experiencing. Hi, I have now tried everything. The last chance is that you are able to unlock the database and export my "Jubula Release Test" project. I have uploaded the database to dropbox: http://dl.dropbox.com/u/5235970/database.zip Hopefully you are able to download it otherwise please advice me how to upload it to you. Maybe you have a ftp site? Please have a look as soon as possible! I need to know latest monday 12/12 if it's possible to export my project. Otherwise I have to start re-doing the work, because I need to run the Jubula test cases next week. Regards Richard I've downloaded your database file(s) and debugged an initial connection attempt to the corresponding database. The cause of the problem is an OutOfMemoryError. A possible workaround may be to assign the ITE more memory (although I'm not sure how much memory is required, I would assume at least as much as the combined size of the database files). You can change the memory settings in the jubula.ini file in <installation-directory>/jubula. Keep in mind that 32-bit memory constraints hold here, so you will need to start Jubula with a 64-bit VM if you want to assign it more than ca. 1.5 GB (if I recall correctly). I'd recommend switching over to a non-in-memory-database (Oracle, for example) at the next opportunity. That should clear up this particular memory problem. The reason that we had so much trouble diagnosing this issue is bug_333749. (In reply to comment #23) > I've downloaded your database file(s) and debugged an initial connection > attempt to the corresponding database. The cause of the problem is an > OutOfMemoryError. A possible workaround may be to assign the ITE more memory > (although I'm not sure how much memory is required, I would assume at least as > much as the combined size of the database files). You can change the memory > settings in the jubula.ini file in <installation-directory>/jubula. Keep in > mind that 32-bit memory constraints hold here, so you will need to start Jubula > with a 64-bit VM if you want to assign it more than ca. 1.5 GB (if I recall > correctly). > > I'd recommend switching over to a non-in-memory-database (Oracle, for example) > at the next opportunity. That should clear up this particular memory problem. > > The reason that we had so much trouble diagnosing this issue is bug_333749. Thanks a million!! Now it works. The bug is solved. Regards Richard Glad to hear that that solved the problem. Resolving as INVALID because: 1. No changes were made to the code base in order to resolve the issue. 2. The OutOfMemoryError is not a Jubula-specific problem. 3. The proposed configuration change resolved the issue. As per Zeb's comment, I am closing this ticket. Hello,
Would you guys be OK if I deleted the 1.16 GB attachment (attachment 207647 [details])? When someone requests this bug in XML format is causes Bugzilla to consume insane amounts of memory.
OK with me. Regards Richard (In reply to comment #27) > Hello, > > Would you guys be OK if I deleted the 1.16 GB attachment (attachment 207647 [details] > [details])? When someone requests this bug in XML format is causes Bugzilla > to consume insane amounts of memory. Please do so. Thanks Achim The content of attachment 207647 [details] has been deleted by Denis Roy <denis.roy@eclipse.org> who provided the following reason: Large attachment was causing problems for Bugzilla's XML engine The token used to delete this attachment was generated at 2013-05-16 10:32:01 EDT. Thanks, guys. The XML view now renders properly. |