topic Re: 4.0.e CE to 4.2.b - strange results. in Alfresco Archive

4.0.e CE to 4.2.b - strange results.

ttownsend — Mon, 29 Oct 2012 04:37:25 GMT

Hello all,I've upgraded my 4.0.e install to 4.2.b and notice that my dashlets for Content I'm Editing and My Documents are broken and showing errors.Here's what I did (following this:http://yogeshpj.blogspot.ca/2012/04/alfresco-cold-backup-and-restore-using.html)From 4.0.etopped the Tomcat server

Re: 4.0.e CE to 4.2.b - strange results.

ekimnosneb — Mon, 29 Oct 2012 11:38:36 GMT

While I can't speak to your pdfbox errors, I was seeing the same results with the search and dashlets myself when upgrading from 4.0.d to 4.2.a. The fix for me was to switch back to the Lucene index from Solr. I was planning to try upgrading my 4.2.a to 4.2.b to see if I could use Solr again, but if you're seeing the same issue, I may wait.

Re: 4.0.e CE to 4.2.b - strange results.

ttownsend — Mon, 29 Oct 2012 12:51:45 GMT

While I can't speak to your pdfbox errors, I was seeing the same results with the search and dashlets myself when upgrading from 4.0.d to 4.2.a. The fix for me was to switch back to the Lucene index from Solr. I was planning to try upgrading my 4.2.a to 4.2.b to see if I could use Solr again, but if you're seeing the same issue, I may wait.

Many thanks for the reply - could you tell me how you switched to Lucene from Solr? I'm not worried at all about time needed to re-index my repository.

Cheers!

Re: 4.0.e CE to 4.2.b - strange results.

abarisone — Mon, 29 Oct 2012 13:01:40 GMT

Hi,
to switch from SolR to Lucene first of all modify this section in alfresco-global.poperties like this

### Solr/Lucene indexing ###
index.subsystem.name=lucene
#dir.keystore=${dir.root}/keystore
#solr.port.ssl=8443‍‍‍‍

In order to perform a full reindex you have to

stop Alfresco

modify alfresco-global.properties adding the property index.recovery.mode=FULL

restart Alfresco in order to let the index being rebuilt

stop Alfresco again

modify alfresco-global.properties modifying the property index.recovery.mode=AUTO

start Alfresco

Regards,
Andrea

Re: 4.0.e CE to 4.2.b - strange results.

ttownsend — Mon, 29 Oct 2012 13:06:24 GMT

Hi Andrea -

Thanks very much; I'm going to try this later this afternoon and let you know how it worked out. In fact, I might just start from scratch and do this before I launch 4.2.b for the first time - I'm still concerned that (see my original post) that a directory /opt/alfresco-4.0.e was created parallel to the new install at /opt/alfresco-4.2.b I think that might have happened because there is a setting somewhere in a solr config file that names /opt/alfresco-4.0.e as the location of solr home or some other setting, and so alfresco creates that directory when it starts. Does that sound possible?

Cheers,
Trevor

Re: 4.0.e CE to 4.2.b - strange results.

michaelk — Mon, 29 Oct 2012 21:10:19 GMT

I had the same problem and after much trial and error ended up with a fix …

https://forums.alfresco.com/en/viewtopic.php?f=8&t=46916

cheers,
Michael

Re: 4.0.e CE to 4.2.b - strange results.

ttownsend — Tue, 30 Oct 2012 13:50:59 GMT

Hi all,

Andrea - because I might be able to save my SOLR install, I'm going to try Michael's fix first.

Michael - I followed your steps. I did skip the keystore step because I was ready to roll this back to a snapshot and try again anyways. Here are the results: All dashlets are reporting reporting correctly; and catalina.out is showing SSL-related errors, see below -


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 sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1902)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:276)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1338)
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:154)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1032)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1328)
        at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702)
        at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.write(BufferedOutputStream.java:121)
        at java.io.FilterOutputStream.write(FilterOutputStream.java:97)
        at org.apache.commons.httpclient.methods.ByteArrayRequestEntity.writeRequest(ByteArrayRequestEntity.java:90)
        at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:499)
        at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)
        at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
        at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
        at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
        at org.alfresco.httpclient.AbstractHttpClient.executeMethod(AbstractHttpClient.java:130)
        at org.alfresco.httpclient.AbstractHttpClient.sendRemoteRequest(AbstractHttpClient.java:106)
        at org.alfresco.httpclient.HttpClientFactory$HttpsClient.sendRequest(HttpClientFactory.java:364)
        at org.alfresco.solr.client.SOLRAPIClient.getModelsDiff(SOLRAPIClient.java:1033)
        at org.alfresco.solr.tracker.CoreTracker.trackModels(CoreTracker.java:1787)
        at org.alfresco.solr.tracker.CoreTracker.trackRepository(CoreTracker.java:1126)
        at org.alfresco.solr.tracker.CoreTracker.updateIndex(CoreTracker.java:472)
        at org.alfresco.solr.tracker.CoreTrackerJob.execute(CoreTrackerJob.java:45)
        at org.quartz.core.JobRunShell.run(JobRunShell.java:216)
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:563)
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:385)
        at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
        at sun.security.validator.Validator.validate(Validator.java:260)
        at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
        at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
        at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1320)
        … 28 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:196)
        at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268)
        at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
        … 34 more
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I'm next going to try the step I omitted and check the results again, but I've never rebuilt keys in a keystore before - what were the steps you used?

1. Do ./alfresco.sh stop
2. ./generate_keystores.sh in alf_data/keystore/ (follow the prompts, I guess?)
3. Do ./alfresco.sh start

Would that be basically correct?

UPDATE:

I rebuilt the keystore the following way:
1. I edited alf_data/keystore/generate-keystores.sh so that;
# Alfresco installation directory
ALFRESCO_HOME=/opt/alfresco-4.2.b (the original file sets ALFRESCO_HOME=/opt/alfresco-4.1)
2. Did ./alf_data/keystore/generate-keystores.sh
3. Did ./alfresco.sh start in /opt/alfresco-4.2.b
4. Watched catalina.out for any errors.

Not one single error. None.
No errors in any Share dashlets. None.

Scha–wiiiing!

Thanks to everyone!

Re: 4.0.e CE to 4.2.b - strange results.

jonvargas — Fri, 02 Nov 2012 03:59:16 GMT

Hi,

I think your pdfbox errors are related to Solr indexation process.

Did you also migrated solr indexes? If not, it's possible that Solr is trying to index your whole repository.

Take a look at your CPU consumption, if java process is taking so much CPU and the server should be idle, it could be Solr performing a full indexation.

It would take some time, depending of the size and type of content in your repository. For example, 8Gb would take around 20 mins, but it really depends on the CPU speed, type and amout of data.

Switching to Lucene is just a fallback.

Give it some time. If it doesn't stop after 24 hours, you need to worry about it 🙂

Re: 4.0.e CE to 4.2.b - strange results.

ttownsend — Fri, 02 Nov 2012 05:07:07 GMT

Hi John,

Pretty sure that SOLR indexing was the culprit. My repository is +/- 25 GB and took about 45-60 minutes (4 core virtual machine, 4GB, Ubuntu on VM Workstation 8, intel i7-920, RAID 1).

All is good now and have not seen any other instances of that error since SOLR rebuilt its indexes.

Cheers!