Infrastructure at your Service

Morgan Patou

Exception from executeScript in Alfresco Share

I didn’t have the opportunity to post a new entry about Alfresco in this blog for a long time now, so I will fix this! In this blog entry, I will talk about a bug I encountered a few months ago. I resolved it but I, so far, not had the time to share my knowledge with you.

I. Description of the issue

This bug appears no matter what the version of Alfresco is used, regardless of the components that are installed, aso… So what is this bug? In fact, this bug isn’t blocking anything. Actually it has no impact on the daily work, however, it fills up the Alfresco log files very quickly which can be problematic if you are an administrator searching for information in these log files! Indeed, each time a user accesses a page of Alfresco, between 10 and 50 Java Exceptions are generated (always the same), this create gigabytes log files in minutes/hours. Here is the exception I’m talking about:

...
Jul 08, 2014 10:42:16 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 95898 ms
2013-07-08 10:45:02,300 INFO [web.site.EditionInterceptor] [http-apr-8080-exec-1] Successfully retrieved license information from Alfresco.
2013-07-08 10:45:02,417 ERROR [extensions.webscripts.AbstractRuntime] [http-apr-8080-exec-3] Exception from executeScript - redirecting to status template error: 06080001 Unknown method specified to remote store API: has
org.springframework.extensions.webscripts.WebScriptException: 06080001 Unknown method specified to remote store API: has
at org.alfresco.repo.web.scripts.bean.BaseRemoteStore.execute(BaseRemoteStore.java:326)
at org.alfresco.repo.web.scripts.RepositoryContainer$3.execute(RepositoryContainer.java:426)
at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:433)
at org.alfresco.repo.web.scripts.RepositoryContainer.transactionedExecute(RepositoryContainer.java:495)
at org.alfresco.repo.web.scripts.RepositoryContainer.transactionedExecuteAs(RepositoryContainer.java:533)
at org.alfresco.repo.web.scripts.RepositoryContainer.executeScript(RepositoryContainer.java:276)
at org.springframework.extensions.webscripts.AbstractRuntime.executeScript(AbstractRuntime.java:377)
at org.springframework.extensions.webscripts.AbstractRuntime.executeScript(AbstractRuntime.java:209)
at org.springframework.extensions.webscripts.servlet.WebScriptServlet.service(WebScriptServlet.java:118)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.alfresco.web.app.servlet.GlobalLocalizationFilter.doFilter(GlobalLocalizationFilter.java:61)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1813)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
...

The first time I encountered this exception, it was on an Alfresco v4.x installation, up and running for some years with a lot of extensions/customizations (mostly .AMP files). If you need more information about AMPs, it means Alfresco Module Package, it’s the better way to extend Alfresco. Please take a look at some of my old blogs to find information about how to create this kind of stuff!

I had this exception on more than one Alfresco server, and because of that, I firstly thought that this exception came from an AMP… Therefore, I went through all these extensions but despite hours of research, I found nothing.

II. How to replicate the issue

I tried to replicate this issue with a fresh installation of Alfresco, same version, same extensions, aso… But I haven’t been able to do so, at the first place. Finally, one day, I found out that there were something strange with the Alfresco servers on which the Java Exceptions appeared: the “Sites” folder weren’t there. Indeed, after the installation of a new Alfresco server, the deletion of the default site (“Sample: Web Site Design Project”) and the deletion of the “Sites” folder from the Repository browser, the exception appeared magically in the Alfresco log files… Now that we know from where this issue comes from, it’s quite easy to replicate it:

  1. Install a new Alfresco server with the same version from the bundle executable/binaries (quicker)
  2. Start the Alfresco server and open the Alfresco Share UI (http://localhost:8080/share) using the admin account
  3. Navigate to the Sites finder (http://localhost:8080/share/page/site-finder)
  4. Click on “Search” to display all existing sites (only the default one is present: “Sample: Web Site Design Project”)
  5. Click on “Delete” to delete the swsdp site
  6. Navigate to the Repository (http://localhost:8080/share/page/repository)
  7. Remove the “Sites” folder on the Repository page (/Company Home/Sites)
  8. Refresh the page and take a look at your logs

After doing that, you should be able to see a lot of exceptions like the one describe above. Issue replicated!

III. How to solve the issue

Being able to replicate an issue is good, but knowing how to solve it is better!

If the “Sites” folder has been deleted in the first place, it was because the Alfresco Sites weren’t used at all. Therefore, the simplest solution to resolve this issue was to get the “Sites” folder back. But it’s not that easy because this folder has a particular type, some particular attributes, aso… You can’t just create a new folder, rename it “Sites” and hope that it will work ;). Starting from here, what you can do to solve this issue is:

  1. Restore the “Sites” folder using a backup
  2. Replicate the “Sites” folder from another Alfresco server

If you don’t have a way to restore the “Sites” folder like it was my case (after some months, no backup left), here is what you can do to fix this issue:

Let’s say that the Alfresco server, where the “Sites” folder doesn’t exist anymore, is named “A”. Please take a look at the end of this blog entry for some screenshots that may help you.

  1. Install a new Alfresco server with the same version as “A” from the bundle executable/binaries. This can be on your local machine. Let’s name this Alfresco server “B”
  2. Start the Alfresco server “B” and open the Alfresco Share UI (http://localhost:8080/share) using the admin account
  3. Navigate to the Sites finder (http://localhost:8080/share/page/site-finder)
  4. Click on “Search” to display all existing sites (only the default one is present: “Sample: Web Site Design Project”)
  5. Click on “Delete” to delete the swsdp site
  6. Navigate to the Repository (http://localhost:8080/share/page/repository) (DON’T delete the “Sites” folder)
  7. Configure a replication target on “B” to point to “A” (take a look at the Alfresco doc: http://docs.alfresco.com/4.1/tasks/adminconsole-replication-transfertarget.html)
  8. Enable the replication:
    1. Add the Alfresco Share url and the RepositoryId of “A” into the share-config-custom.xml file of “B” (take a look at the Alfresco doc: http://docs.alfresco.com/4.1/tasks/adminconsole-replication-lockedcontent.html)
    2. Add the “replication.enabled=true” into the alfresco-global.properties file of “B” (take a look at the Alfresco doc: http://docs.alfresco.com/4.1/tasks/replication-share.html)
    3. Restart “B” for the changes to be taken into account by Alfresco
  9. Configure a replication job on “B” to replicate the “Sites” folder from “B” to “A” (http://localhost:8080/share/page/console/admin-console/replication-jobs)
  10. Run the replication job on “B”

Configure the Replication Target on B (step 7 – create a folder named “TransfertToA” and edit its permissions):

CreateReplicationTarget.png

Find the Repository ID of A (step 8.1):

FindRepositoryId.png

Configure the share-config-custom.xml file of B (step 8.1):

EnableTheReplication.png

Once the replication job has run on “B”, the exceptions will disappear from the log files of “A”. I didn’t go deeper so I don’t really know if you can create new sites using this newly imported “Sites” folder but if you removed this folder in the first place, I would guess that you don’t really need it ;).

Thank you for reading this post and I hope this will help. If you need more information, don’t hesitate to let a little comment below. See you soon for more blogs!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Morgan Patou
Morgan Patou

Technology Leader ECM & Senior Consultant