Project

General

Profile

Bug #4907

Replication error stops insert/update of valid EML document

Added by Duane Costa over 10 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Normal
Category:
metacat
Target version:
Start date:
03/29/2010
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
4907

Description

It appears that a replication error causes insert/update to fail that would otherwise succeed:

On March 26, 2010, Margaret O'Brien wrote:

Hi Duane -
I am trying to do a document update to the LTER network catalog from the Metacat XML loader at:
http://metacat.lternet.edu/knb/style/skins/dev/loadxml.jsp
after logging in as user=sbc here:
http://metacat.lternet.edu/knb/style/skins/dev/login.html
I get this error:
<error>
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
</error>
The document was valid EML 2.0.1. Can you help? I asked Mike Daigle, and he says he has seen this occasionally during replication.

thanks -
Margaret O'Brien

I repeated this same procedure, using the same EML document that Margaret tried to update, on two different Metacat servers:

(1) The first server was a test instance of Metacat which had no replication configured. The document was successfully inserted without errors.

(2) The second server was the LTER production server which replicates to the KNB server. This result I got was identical to Margaret's. The document failed to update, but the error message seemed to involve replication; there was no indication of any problem with the document itself.

So it appears that there might be a logical flaw in the insert/update process, where a replication issue can prevent an insert/update from succeeding. My expectation would be that insert/update should not depend on replication succeeding first. (There is, of course, a dependency in the other direction: replication depends on the insert/update succeeding first.)

Below is the full traceback from the Tomcat log file on host metacat.lternet.edu:

2010-03-26 08:14:28.721 Data Portal: [WARN] [edu.ucsb.nceas.metacat.MetaCatServlet]: Error in writing eml document to the databasesun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1035)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:124)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1139)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:418)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1041)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
at java.net.URL.openStream(URL.java:1009)
at edu.ucsb.nceas.metacat.MetacatReplication.getURLContent(MetacatReplication.java:1970)
at edu.ucsb.nceas.metacat.DocumentImpl.write(DocumentImpl.java:2577)
at edu.ucsb.nceas.metacat.DocumentImpl.write(DocumentImpl.java:2497)
at edu.ucsb.nceas.metacat.DocumentImplWrapper.write(DocumentImplWrapper.java:63)
at edu.ucsb.nceas.metacat.MetaCatServlet.handleInsertOrUpdateAction(MetaCatServlet.java:2160)
at edu.ucsb.nceas.metacat.MetaCatServlet.handleGetOrPost(MetaCatServlet.java:726)
at edu.ucsb.nceas.metacat.MetaCatServlet.doPost(MetaCatServlet.java:359)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:122)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:285)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:191)
at sun.security.validator.Validator.validate(Validator.java:218)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1014)
... 37 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:280)
... 43 more

History

#1 Updated by Duane Costa over 10 years ago

It took a few days to realize what was going on here, but now we think we see the issue. The document's "home server" is recorded in the LTER metacat database as 'data.piscoweb.org/catalog/servlet/replication'. This means that 'metacat.lternet.edu' needs to ask permission from the PISCO server prior to updating the document. A problem with certificates is preventing that exchange from occurring, and thus the LTER metacat is, correctly, refusing to update the document.

Although the Metacat server's behavior was correct (there is no logical error as was originally thought), the error message was very cryptic, so I will leave this Metacat bug open, decrease its priority, and just change the bug to a request for a more informative error diagnostic when this condition arises.

#2 Updated by ben leinfelder about 9 years ago

Added clearer error handling when replication lock requests cannot be gotten

#3 Updated by Redmine Admin over 7 years ago

Original Bugzilla ID was 4907

Also available in: Atom PDF