Bug #1179
CN VM build process creates metacat failures
100%
History
#1 Updated by Robert Waltz almost 14 years ago
- Assignee set to Robert Waltz
- Milestone set to CCI-0.5
- Category set to d1_cn_buildout
The cn-ucsb-1 demo node's metacat failed on create with a strange postgresql error.
We found that cn-ucsb-1 nodes debian packages varied from the other demo cn nodes.
cn-ucsb-1 was built out using an Ubuntu Server 9.10 CD while the other nodes were created using vmbuilder.
cn-ucsb-1 is now built with vmbuilder and needs to be compared with a development buildout to ensure that base packages can be recreated in a consistent manner.
After a stable and consistent build process is validated, then build out cn service stack on cn-ucsb-1 and test metacat creates again.
#2 Updated by Robert Waltz almost 14 years ago
Upon update of dataone-cn-metacat on cn-ucsb-1, metacat began reporting the error:
knb 20110106-21:27:31: [FATAL]: DBSaxHandler.fatalError - White spaces are required between publicId and systemId. [edu.ucsb.nceas.metacat.DBSAXHandler]
knb 20110106-21:27:31: [ERROR]: DocumentImpl.write - Problem with parsing: Fatal processing error. [edu.ucsb.nceas.metacat.DocumentImpl]
knb 20110106-21:27:31: [WARN]: MetaCatServlet.handleInsertOrUpdateAction - General error when writing eml document to the database: Fatal processing error. [edu.ucsb.nceas.metacat.MetaCatServlet]
I updated a personal vm that was setup to the spec cn-ucsb-1 was setup, upon update of dataone-cn-metacat, I am still able to create without error.
#3 Updated by Robert Waltz almost 14 years ago
we created a clean vm on cn-unm-1 like as on cn-ucsb-1, and there being no discernible differences between installs. cn-unm-1's metacat fails on initial install while cn-ucsb-1 succeeded. Upon upgrade of cn-ucsb-1, it failed. On my experimental machine, which has the same setup as cn-unm-1 and cn-ucsb-1, metacat works on initial install and subsequent upgrades.
#4 Updated by Dave Vieglais almost 14 years ago
I have a hunch that this issue is a misconfiguration of the connection between the cn service and the metacat endpoint that is handling the request. It may be related to issues #1200 and #1201.
It doesn't appear that this is a metacat problem directly, but rather metacat is being fed something unpleasant from upstream.
#5 Updated by Dave Vieglais almost 14 years ago
- Target version changed from Sprint-2011.01 to Sprint-2011.02
- Position deleted (
4) - Position set to 25
#6 Updated by Robert Waltz almost 14 years ago
- % Done changed from 0 to 100
- Status changed from New to Closed
Bug was fixed in Metacat. Depending upon the protocol used to update the administrative settings in Metacat would change the port saved for the Server.HTTPPort parameter. Anything other than 80 would cause metacat to fail on create.
