It's all about the answers!

Ask a question

java.lang.IllegalStateException in JBE


Dale Manthei (14185) | asked Jun 03 '08, 10:02 p.m.
Thought I had my build working smoothly with JBE and JUnit tests and
this started happening. Any ideas what went wrong? Or what I have to
do to get the JBE running again?

2008-06-03 21:00:00
2008-06-03 21:00:00 Substituted the following
build property variables:
2008-06-03 21:00:00 buildId =
${buildLabel} --> buildId = C20080603-2100
2008-06-03 21:00:00
2008-06-03 21:00:00
2008-06-03 21:00:00 Substituted the following
configuration element property variables:
2008-06-03 21:00:00
com.ibm.team.build.junit.publishing :
com.ibm.team.build.junit.publishing.log =
C:/JBE_Build/fetched/working.dirs/${buildId}/test.results -->
com.ibm.team.build.junit.publishing.log =
C:/JBE_Build/fetched/working.dirs/C20080603-2100/test.results
2008-06-03 21:00:00
2008-06-03 21:00:00 Should build occur?
2008-06-03 21:00:00 Yes: Always build a user
initiated request.
2008-06-03 21:00:00 Invoking pre-build participant
"com.ibm.team.build.jazzscm"
Accepting changes into workspace "FileNet Plugin Continuous Build
Workspace" ...
Fetching files to fetch destination "C:\JBE_Build\fetched" ...
java.lang.IllegalStateException
at
com.ibm.team.repository.common.internal.content.util.DiskBackedHashMap$EntryIterator.findNextTableEntry(DiskBackedHashMap.java:792)
at
com.ibm.team.repository.common.internal.content.util.DiskBackedHashMap$EntryIterator.next(DiskBackedHashMap.java:775)
at
com.ibm.team.repository.common.internal.content.util.DiskBackedHashMap$EntryIterator.next(DiskBackedHashMap.java:1)
at
com.ibm.team.filesystem.client.internal.SharingDescriptorsMap.<init>(SharingDescriptorsMap.java:37)
at
com.ibm.team.filesystem.client.internal.SharingMetadata2.initDescriptors(SharingMetadata2.java:983)
at
com.ibm.team.filesystem.client.internal.SharingMetadata2.allShares(SharingMetadata2.java:1241)
at
com.ibm.team.filesystem.client.internal.MetadataChangeTracker.allShares(MetadataChangeTracker.java:329)
at
com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaStore.allSharePaths(CopyFileAreaStore.java:2460)
at
com.ibm.team.filesystem.client.internal.SharingManager.getAllShares(SharingManager.java:225)
at
com.ibm.team.filesystem.client.internal.SharingManager.allShares(SharingManager.java:217)
at
com.ibm.team.filesystem.client.internal.operations.LocalFileSystemLoadOperation.getAllShares(LocalFileSystemLoadOperation.java:152)
at
com.ibm.team.filesystem.client.internal.operations.LoadOperation.organizeShares(LoadOperation.java:980)
at
com.ibm.team.filesystem.client.internal.operations.LoadOperation.getElementsToLoad(LoadOperation.java:726)
at
com.ibm.team.filesystem.client.internal.operations.LoadOperation.evaluateLoadRequests(LoadOperation.java:290)
at
com.ibm.team.filesystem.client.internal.operations.LoadOperation.doLoad(LoadOperation.java:416)
at
com.ibm.team.filesystem.client.internal.operations.LocalFileSystemLoadOperation.execute(LocalFileSystemLoadOperation.java:97)
at
com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:89)
at
com.ibm.team.build.internal.scm.SourceControlUtility.updateFileCopyArea(SourceControlUtility.java:266)
at
com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:149)
at
com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:475)
at
com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:352)
at java.lang.Thread.run(Thread.java:735)

2 answers



permanent link
Don Weinand (7851) | answered Jun 04 '08, 10:36 a.m.
JAZZ DEVELOPER
This looks similar to a problem we experienced in workitem 49777 and
41956...hidden(and/or old files) were being left around and used causing
corruption. On the Jazz Source Control page of your build definition, is it
set to delete the directory before loading? If you manually delete that
directory before the build does the problem go away?

Don Weinand
Jazz Team Build

"Dale Manthei" <manthei> wrote in message
news:jrtb44pdj0orq2hqcdl01pqgbpbt06ur09@4ax.com...
Thought I had my build working smoothly with JBE and JUnit tests and
this started happening. Any ideas what went wrong? Or what I have to
do to get the JBE running again?

2008-06-03 21:00:00
2008-06-03 21:00:00 Substituted the following
build property variables:
2008-06-03 21:00:00 buildId =
${buildLabel} --> buildId = C20080603-2100
2008-06-03 21:00:00
2008-06-03 21:00:00
2008-06-03 21:00:00 Substituted the following
configuration element property variables:
2008-06-03 21:00:00
com.ibm.team.build.junit.publishing :
com.ibm.team.build.junit.publishing.log =
C:/JBE_Build/fetched/working.dirs/${buildId}/test.results --
com.ibm.team.build.junit.publishing.log =
C:/JBE_Build/fetched/working.dirs/C20080603-2100/test.results
2008-06-03 21:00:00
2008-06-03 21:00:00 Should build occur?
2008-06-03 21:00:00 Yes: Always build a user
initiated request.
2008-06-03 21:00:00 Invoking pre-build participant
"com.ibm.team.build.jazzscm"
Accepting changes into workspace "FileNet Plugin Continuous Build
Workspace" ...
Fetching files to fetch destination "C:\JBE_Build\fetched" ...
java.lang.IllegalStateException
at
com.ibm.team.repository.common.internal.content.util.DiskBackedHashMap$EntryIterator.findNextTableEntry(DiskBackedHashMap.java:792)
at
com.ibm.team.repository.common.internal.content.util.DiskBackedHashMap$EntryIterator.next(DiskBackedHashMap.java:775)
at
com.ibm.team.repository.common.internal.content.util.DiskBackedHashMap$EntryIterator.next(DiskBackedHashMap.java:1)
at
com.ibm.team.filesystem.client.internal.SharingDescriptorsMap.<init>(SharingDescriptorsMap.java:37)
at
com.ibm.team.filesystem.client.internal.SharingMetadata2.initDescriptors(SharingMetadata2.java:983)
at
com.ibm.team.filesystem.client.internal.SharingMetadata2.allShares(SharingMetadata2.java:1241)
at
com.ibm.team.filesystem.client.internal.MetadataChangeTracker.allShares(MetadataChangeTracker.java:329)
at
com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaStore.allSharePaths(CopyFileAreaStore.java:2460)
at
com.ibm.team.filesystem.client.internal.SharingManager.getAllShares(SharingManager.java:225)
at
com.ibm.team.filesystem.client.internal.SharingManager.allShares(SharingManager.java:217)
at
com.ibm.team.filesystem.client.internal.operations.LocalFileSystemLoadOperation.getAllShares(LocalFileSystemLoadOperation.java:152)
at
com.ibm.team.filesystem.client.internal.operations.LoadOperation.organizeShares(LoadOperation.java:980)
at
com.ibm.team.filesystem.client.internal.operations.LoadOperation.getElementsToLoad(LoadOperation.java:726)
at
com.ibm.team.filesystem.client.internal.operations.LoadOperation.evaluateLoadRequests(LoadOperation.java:290)
at
com.ibm.team.filesystem.client.internal.operations.LoadOperation.doLoad(LoadOperation.java:416)
at
com.ibm.team.filesystem.client.internal.operations.LocalFileSystemLoadOperation.execute(LocalFileSystemLoadOperation.java:97)
at
com.ibm.team.filesystem.client.internal.operations.FileSystemOperation.run(FileSystemOperation.java:89)
at
com.ibm.team.build.internal.scm.SourceControlUtility.updateFileCopyArea(SourceControlUtility.java:266)
at
com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:149)
at
com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:475)
at
com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:352)
at java.lang.Thread.run(Thread.java:735)

permanent link
Dale Manthei (14185) | answered Jun 04 '08, 3:18 p.m.
On Wed, 4 Jun 2008 07:36:48 -0700, "Donald Weinand"
<dmweinan> wrote:

This looks similar to a problem we experienced in workitem 49777 and
41956...hidden(and/or old files) were being left around and used causing
corruption. On the Jazz Source Control page of your build definition, is it
set to delete the directory before loading? If you manually delete that
directory before the build does the problem go away?

Don Weinand
Jazz Team Build

I tried the manual clean up and specifying in the build definition to
delete the fetched directories first. Kind of worked one time and
then failed the next.

Some of the problems were due to trying to start the JBE with
different JDKs I think. I noticed earlier that the logs sometimes
said a 1.5 JDK was in use and sometimes a 1.6. Very odd.

I think some of the problem may also have been due to tweaking the
JUnit plug-ins to get plug-in JUnit tests to coexist with Jazz and the
Eclipse Test Framework. After refreshing the install things returned
to normal and life is good again.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.