Error during upload (CRJAZ1247I with http error 500)
We experienced problems late last week trying to update/overwrite two binary jars already under source control. Oddly enough, we had no problems with a third jar that resides along-side these two jars, nor have we had any problems with text files. We eventually got around the delivery errors (shown below) by adding the two problematic jars in an alternate directory, delivered, and then moved (dragged/dropped) the two jars back into their original directory overwriting the two original jars, and then delivered without getting the errors. However, during this workaround, we kept getting messages stating that our repository workspace was out of date and to reload it after each delivery (very strange).
We were wondering if anyone can explain what might have been the problem and how we should go about debugging such SCM situations in the future. The error message indicated that more information could be found in the "server logs" yet we could not find anything related to these errors in the jazz.log or tomcat's catalina.out log. Here are the error messages that we got during delivery: Error during upload Failed to upload File /ws_ast_common/lib/fesco-commons-svc-message.jar CRJAZ1247I The request to the server failed. The server returned the http error 500 with error text "Internal Server Error". Examine further details here or look in the server logs for more information. Failed to upload File /ws_ast_common/lib/fesco-commons-svc-auth.jar CRJAZ1247I The request to the server failed. The server returned the http error 500 with error text "Internal Server Error". Examine further details here or look in the server logs for more information. A search of forum resulted in other reports of CRJAZ1247I errors but with http error 400 (none with http error 500). One of these forum postings (http://jazz.net/forums/viewtopic.php?t=8415&highlight=crjaz1247i) seemed to indicate the file Properties -> Jazz Source Control were not set, however we checked, and they were set as expected: MIME type = application/unknown , Line Delimiter = None (binary). We could not find any obvious differences between the jar that worked and the two jars that failed. Thanks in advance - Tim |
6 answers
|
Hi Geoff,
Thanks but we believe we have identified and fixed the problem. The same error (CRJAZ1274I) occurred in another RTC project yesterday and we found the key information in the end-user's local eclipse log (not in the 'server logs' as the error message indicated). The local eclipse log file is located here Documents and Settings\<corpid>\<eclipse_workspace>/.metadata/.log The local eclipse log told us the following: Caused by: com.ibm.team.repository.common.TeamRepositoryException: The versioned content service temp directory has been deleted. This often can happen if the property 'vcs.tmpdir' is a directory within /tmp. Please contact your server administrator. So we then set the vcs.tmpdir variable to /var/tmp/versionedcontentservice, created this directory under /var/tmp, and the user was able to deliver without issue. Hi Tim, We experienced problems late last week trying to update/overwrite two |
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 22 '10, 9:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Tim,
Unless you get a quick answer from the forum, you'll want to submit a trouble ticket to support so they can help you track this down. The first thing they'll ask is if you can reproduce the problem. Cheers, Geoff On 11/22/2010 9:53 AM, timothy.mulligan wrote: We experienced problems late last week trying to update/overwrite two |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 24 '10, 12:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I've submitted work item 140561 to get the error message improved.
A couple of pointers: - Type in the error ID into the Eclipse "work item search" field (bottom left). It will often point you at some work items with some tips (it would in this case). - Type in the error ID into Google. In this case, it would have pointed you at an article on jazz.net, that would have given you the pointer that you found in the eclipse.log Cheers, Geoff On 11/23/2010 11:53 AM, timothy.mulligan wrote: we believe we have identified and fixed the problem. The |
I've submitted work item 140561 to get the error message improved. we believe we have identified and fixed the problem. The Is there a way to avoid that behavior? Why was this folder deleted? I have a customer with the same issue. Then he restarted the server and the error message is no longer happening. Ricardo |
|
We do not know how the directory that is associated with the 'vcs.tmpdir' property got deleted. We did not delete it. However be careful because there are two closely related variables and this tripped us up for a while.
Versionable Content Temporary Directory (this is vcs.tmpdir) = /var/tmp/versionedcontentservice and Content Temporary Directory = /var/tmp/contentservice /var/tmp/versionedcontentservice did not exist. We created it and the user was then able to deliver w/o issue. Geoff - thanks for submitting work item to improve error message! -Tim I've submitted work item 140561 to get the error message improved. we believe we have identified and fixed the problem. The Is there a way to avoid that behavior? Why was this folder deleted? I have a customer with the same issue. Then he restarted the server and the error message is no longer happening. Ricardo |
Hi Ricardo,
Sometimes /var/tmp and /tmp are periodically cleaned by OS. |
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.