Community
Participate
Working Groups
Build Identifier: Eclipse 3.7.1.v201109091335 and OSEE 0.9.9.v201112050021 We had created a Postgresql db using a OSEE client and version built with 0.9.9_SR2 branch source code. With the latest OSEE client and server OSEE_0.9.9_SR3_20111205 , server started , client also started but when we got to any of the OSEE perspectives , it gives the below exception. On Analysis we found that it connects to App server, connects to db but session creation fails. Can you advice what needs to be done for this case. Error Wed Dec 28 12:12:47 IST 2011 Atrifact type: 289 is not available. org.eclipse.osee.framework.core.exception.OseeTypeDoesNotExist: Atrifact type: 289 is not available. at org.eclipse.osee.framework.skynet.core.artifact.ArtifactTypeManager.getType(ArtifactTypeManager.java:134) at org.eclipse.osee.framework.skynet.core.artifact.ArtifactLoader.retrieveShallowArtifact(ArtifactLoader.java:309) at org.eclipse.osee.framework.skynet.core.artifact.ArtifactLoader.loadArtifactsFromQueryId(ArtifactLoader.java:105) at org.eclipse.osee.framework.skynet.core.artifact.ArtifactLoader.loadArtifacts(ArtifactLoader.java:206) at org.eclipse.osee.framework.skynet.core.artifact.ArtifactLoader.loadArtifacts(ArtifactLoader.java:190) at org.eclipse.osee.framework.skynet.core.artifact.ArtifactLoader.getArtifacts(ArtifactLoader.java:64) at org.eclipse.osee.framework.skynet.core.artifact.search.ArtifactQueryBuilder.internalGetArtifacts(ArtifactQueryBuilder.java:525) at org.eclipse.osee.framework.skynet.core.artifact.search.ArtifactQueryBuilder.getArtifacts(ArtifactQueryBuilder.java:497) at org.eclipse.osee.framework.skynet.core.artifact.search.ArtifactQuery.getArtifactListFromType(ArtifactQuery.java:316) at org.eclipse.osee.framework.skynet.core.UserManager.ensurePopulated(UserManager.java:230) at org.eclipse.osee.framework.skynet.core.UserManager.createUser(UserManager.java:265) at org.eclipse.osee.framework.skynet.core.UserManager.createMainUser(UserManager.java:259) at org.eclipse.osee.framework.skynet.core.ClientUser.populateCurrentUser(ClientUser.java:77) at org.eclipse.osee.framework.skynet.core.ClientUser.getMainUser(ClientUser.java:51) at org.eclipse.osee.framework.skynet.core.UserManager.getUser(UserManager.java:64) at org.eclipse.osee.framework.ui.skynet.SessionContributionItem.getEnabledToolTip(SessionContributionItem.java:139) at org.eclipse.osee.framework.ui.plugin.OseeStatusContributionItem$1.run(OseeStatusContributionItem.java:59) at org.eclipse.osee.framework.ui.swt.Displays.ensureInDisplayThread(Displays.java:38) at org.eclipse.osee.framework.ui.swt.Displays.ensureInDisplayThread(Displays.java:28) at org.eclipse.osee.framework.ui.plugin.OseeStatusContributionItem.updateStatus(OseeStatusContributionItem.java:55) at org.eclipse.osee.framework.ui.skynet.SessionContributionItem.<init>(SessionContributionItem.java:51) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at org.eclipse.osee.framework.ui.skynet.OseeStatusContributionItemFactory.createItem(OseeStatusContributionItemFactory.java:50) at org.eclipse.osee.framework.ui.skynet.OseeStatusContributionItemFactory.addTo(OseeStatusContributionItemFactory.java:37) at org.eclipse.osee.framework.ui.skynet.OseeStatusContributionItemFactory.addTo(OseeStatusContributionItemFactory.java:72) at org.eclipse.osee.ats.navigate.NavigateView$ReloadJobChangeAdapter$1.runInUIThread(NavigateView.java:176) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) Reproducible: Always
Created attachment 209119 [details] The Artifact Cache file Please find the Artifact cache xml file. I found that the Artifact type 289 was not loaded. In such cases what should be done.
It looks like the remote_id to local_id mapping might not be correct. Upgrading from 0.9.9_SR2 to 0.9.9_SR3 should not have caused this data to change. The next step is to investigate what type the local_id 289 maps to. Please run the following SQL queries and post the results: select * from osee_type_id_map where local_id = 289; select * from osee_type_id_map where remote_id = 5; select distinct remote_id from osee_artifact art, osee_attribute attr, osee_type_id_map type_id where art.art_type_id = 289 and art.art_id = attr.art_id and attr.attr_type_id = type_id.local_id;
(In reply to comment #2) > It looks like the remote_id to local_id mapping might not be correct. > Upgrading from 0.9.9_SR2 to 0.9.9_SR3 should not have caused this data to > change. The next step is to investigate what type the local_id 289 maps to. > Please run the following SQL queries and post the results: > > select * from osee_type_id_map where local_id = 289; > select * from osee_type_id_map where remote_id = 5; > > select distinct remote_id from osee_artifact art, osee_attribute attr, > osee_type_id_map type_id where > art.art_type_id = 289 and art.art_id = attr.art_id and attr.attr_type_id = > type_id.local_id; Hi, I tried to reproduce on another collegue machine i got exceptio for type "297" I tried the given sql queries and the results are as follows, "local_id";"remote_id" 297;5 "remote_id" 1152921504606847073 1152921504606847088 1152921504606847065 1152921504606847082 1152921504606847076 Please let me know if this helps. regards, Swapna
Created attachment 209304 [details] OSEE_Cache contents for artifact type 297 not found exception
(In reply to comment #4) > Created attachment 209304 [details] > OSEE_Cache contents for artifact type 297 not found exception I did a restart several times and it didnot help. I closed all the client instances that were running and eventually all clients were not able to login. We tried to start server , reload cache at the server several times and once it worked. So not very sure why the cache loading has this problem. Can you provide more information why such cache reloading would occur and if it occurs what could be done ?
The longer of the three queries that involved the osee_attribute table and art.art_type_id = 289 tells us something important. The five remote_ids are for attribute types that would belong on a user artifact. This means that in your database there are a number of artifacts with local artifact type 289 that are really User artifacts which is consistent with the stacktrace from the exception you got because it happened while the UserManager was loading the user cache. The problem is that according to the type information in your application server (based on the xml you posted), the User artifact type has a local id of 297 not 289 and a remote id of 5. Please let me know the results of the first query: select * from osee_type_id_map where local_id = 289; Has something happened during the history of your database that may have changed the type definitions? Thanks, Ryan
(In reply to comment #6) > The longer of the three queries that involved the osee_attribute table and > art.art_type_id = 289 tells us something important. The five remote_ids are > for attribute types that would belong on a user artifact. This means that in > your database there are a number of artifacts with local artifact type 289 that > are really User artifacts which is consistent with the stacktrace from the > exception you got because it happened while the UserManager was loading the > user cache. > > The problem is that according to the type information in your application > server (based on the xml you posted), the User artifact type has a local id of > 297 not 289 and a remote id of 5. > > Please let me know the results of the first query: > select * from osee_type_id_map where local_id = 289; > > > Has something happened during the history of your database that may have > changed the type definitions? > > Thanks, > Ryan Hi Ryan, Due to certain reasons we reinitialized the db after we raised this question. We again could reproduce this scenario, the second time the artifact type is 297, which is again a User artifact with remote id of 5. and my previous attachement has all the query results. Since i have reinitialized the db the artifact 289 is not there which is instead 297.
