I set "solr.server" to use port 8080 in /dspace/config/dspace.cfg as well
as "server" in solr-statistics.cfg and "solr.url" in oai.cfg.
Looks like progress, it still fails but the error messages changed:
2018-10-19 12:58:58,999 ERROR
org.dspace.app.xmlui.aspect.statistics.StatisticsTransformer @ Error
occurred while creating statistics for home page
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
Expected mime type application/octet-stream but got text/html. <!DOCTYPE
html><html><head><title>Apache Tomcat/9.0.0.M17 - Error
report</title><style type="text/css">h1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
h2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
h3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
body
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} b
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
p
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}
a {color:black;} a.name {color:black;} .line
{height:1px;background-color:#525D76;border:none;}</style>
</head><body><h1>HTTP Status 404 - /solr/select</h1><div
class="line"></div><p><b>type</b> Status report</p><p><b>message</b>
<u>/solr/select</u></p><p><b>description</b> <u>The requested resource is
not available.</u></p><hr class="line"><h3>Apache
Tomcat/9.0.0.M17</h3></body></html>
at
org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:512)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:210)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:206)
at
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
...
On Friday, October 19, 2018 at 11:36:45 AM UTC-8, Sean Kalynuk wrote:
>
> Hi Walter,
>
>
>
> Since there is redirect logic involved, how about updating your
> solr.server parameter to point directly to the Tomcat solr webapp on port
> 8080?
>
>
>
> solr.server = http://localhost:8080/solr
>
>
>
> Not entirely sure, but I’m guessing this type of change requires a Tomcat
> restart.
>
>
>
> --
>
> Sean
>
>
>
> *From:* dspac...@googlegroups.com <javascript:> <dspac...@googlegroups.com
> <javascript:>> *On Behalf Of *wlruth...@alaska.edu <javascript:>
> *Sent:* October 19, 2018 2:26 PM
> *To:* DSpace Technical Support <dspac...@googlegroups.com <javascript:>>
> *Subject:* Re: [dspace-tech] View Statistics links not working
>
>
>
>
>
> Hey Sean,
>
>
>
> I started to say I saw nothing in the logs but I just saw a redirection
> error in dspace.log.2018-10-19 that I haven't seen before:
>
> 2018-10-19 10:51:13,345 ERROR
> org.dspace.app.xmlui.aspect.statistics.StatisticsTransformer @ Error
> occurred while creating statistics for home page
>
> org.apache.solr.client.solrj.SolrServerException: Server at
> http://localhost/statistics sent back a redirect (302).
>
> ...
>
> Rather than include the entire ~180 line stack trace, here is the
> /etc/httpd/conf.d/vhosts.conf file which handles HTTP redirection although
> I think
>
> we may have been having problems with the statistics links even before
> adding this file:
>
> [root@dspace36a conf.d]# cat vhosts.conf
>
> <VirtualHost *:80>
>
> #
>
> ### Redirect insecure ports to secure port 443
>
> ServerAdmin uaf-library-it-d...@alaska.edu <javascript:>
>
> RewriteEngine On
>
> RewriteCond %{HTTPS} off
>
> RewriteRule (.*) https://%{HTTP_HOST}:443%{REQUEST_URI} [R,L]
>
> DocumentRoot /dspace/webapps/xmlui
>
> ServerName dspace36a.library.uaf.edu
>
> ServerAlias scholarworks
>
>
>
> ErrorLog logs/dspace36a.library.uaf.edu-error_log
>
> CustomLog logs/dspace36a.library.uaf.edu-access_log common
>
> RewriteLog logs/dspace36a-rewrite
>
>
>
> ProxyPass / http://127.0.0.1:443/ retry=10 connectiontimeout=5
>
> ### ^ this tells httpd to redirect it's / to localhost port 443
>
>
>
> #timeout=300
>
> ProxyPassReverse / http://127.0.0.1:443/ retry=10
>
> ### ^ this tells httpd that tomcat's url's should be rewritten to
> look
>
> ### like they're coming from httpd.
>
>
>
> # ProxyPreserveHost On
>
> ### ^ this tells httpd to keep the Host: information from the
> client and
>
> ### pass it on to tomcat.
>
>
>
> </VirtualHost>
>
>
>
> #<VirtualHost dspace36a.library.uaf.edu:443>
>
> <VirtualHost *:443>
>
> ### ^ this creates a httpd server that listens on port 443.
>
>
>
> ServerAdmin uaf-library-it-d...@alaska.edu <javascript:>
>
> DocumentRoot /dspace/webapps/xmlui
>
> ServerName dspace36a.library.uaf.edu
>
> ServerAlias scholarworks
>
>
>
> ErrorLog logs/dspace36a.library.uaf.edu-https-error_log
>
> CustomLog logs/dspace36a.library.uaf.edu-https-access_log
> combinedssl
>
> RewriteLog logs/dspace36a-rewrite
>
>
>
> Include conf.d/ssl.include
>
> Include conf.d/ssl.include.star
>
> ### ^ these point to a file which specifies where the ssl
> certificates
>
> ### live on the host.
>
>
>
> ProxyPass / http://127.0.0.1:8080/ retry=10
> connectiontimeout=5
>
> # ProxyPass / http://127.0.0.1:443/ retry=10
> connectiontimeout=5
>
> ### ^ this tells httpd to redirect it's / to localhost port 8080
>
>
>
> #timeout=300
>
>
>
> ProxyPassReverse / http://127.0.0.1:8080/ retry=10
>
> # ProxyPassReverse / http://127.0.0.1:443/ retry=10
>
> ### ^ this tells httpd that tomcat's url's should be rewritten to
> look
>
> ### like they're coming from httpd.
>
>
>
> ProxyPreserveHost On
>
> ### ^ this tells httpd to keep the Host: information from the
> client and
>
> ### pass it on to tomcat.
>
>
>
> </VirtualHost>
>
>
>
> Ports 80, 443, 8000, and 8080 are active for TCP. Port 8000 is used by the
> handle-server but 8080 should also be unsecured.
>
>
>
>
>
> On Friday, October 19, 2018 at 8:46:33 AM UTC-8, Sean Kalynuk wrote:
>
> Hi Walter,
>
>
>
> Do you see errors in the logs when visiting the following page?
>
>
>
> https://dspace36a.library.uaf.edu/search-statistics
>
>
>
> At least on that page I got “There was an error while generating the
> search statistics, please try again later.”
>
>
>
> You can also see an error message when visiting
>
>
>
> https://dspace36a.library.uaf.edu/workflow-statistics
>
>
>
> --
>
> Sean
>
>
>
> *From:* dspac...@googlegroups.com <dspac...@googlegroups.com> *On Behalf
> Of *wlruth...@alaska.edu
> *Sent:* October 18, 2018 2:52 PM
> *To:* DSpace Technical Support <dspac...@googlegroups.com>
> *Subject:* Re: [dspace-tech] View Statistics links not working
>
>
>
> This is maddening and taking far longer than it should, mostly because I
> can't tell where the problem is located.
>
> I've setup all of the configuration variables mentioned in the manual but
> I'm not seeing anything in the logfiles
>
> that says what's wrong. It could be a combination of Tomcat/DSpace, httpd,
> solr, ... The only other similar posts
>
> I've seen here haven't had solutions. It doesn't help that I haven't see
> the statistics links working so I'm not quite
>
> sure even what to expect.
>
>
>
> For example: I can see https://dspace36a.library.uaf.edu/solr but that
> looks more like an administrator page. But
>
> I don't need to be logged in at all to see it and I'm pretty sure that's
> not the statistics page. If I try this instead:
>
> https://dspace36a.library.uaf.edu/statistics I get an entirely blank
> page. In my experience that means it's being
>
> handled (it's not returning an error) but the output is null.
>
>
>
> I can attach config files or logs but which would be most useful to help
> troubleshoot this problem?
>
>
>
> Thank you.
>
>
>
> Walter R.
>
>
>
>
> On Wednesday, October 10, 2018 at 12:17:03 PM UTC-8, wlruth...@alaska.edu
> wrote:
>
> I am occasionally seeing errors like this in the catalina.out file:
>
> Error using query type: 2
>
> [WARN] deprecation - The 'component-configurations' section in the sitemap
> is deprecated. Please check for alternatives.
>
> Error using query *:*
>
> Error using query statistics_type:workflow AND NOT(previousWorkflowStep:
> SUBMIT)
>
> Error using query type: 2 AND id:2695
>
> Error using query type: 0 AND owningItem:2695
>
> Error using query type: 2 AND id:3677
>
> Error using query type: 0 AND owningItem:3677
>
> The four digit numbers appear to be valid item numbers so I'm not sure
> what's generating the errors. So I'm slogging
>
> through the manual and sitemaps to see if I can trace what happens when
> the "View Usage Statistics" link is clicked.
>
>
>
>
>
>
> On Tuesday, October 9, 2018 at 2:48:54 PM UTC-8, wlruth...@alaska.edu
> wrote:
>
> Rats... couldn't be that easy.
>
>
>
> Finding very few non-INFO messages in the logs. I did find an entry in
> catalina.out that at least tells me it is/was running solr (perhaps with
> memory leaks).
>
> 01-Jun-2017 01:23:38.504 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [solr] appears to have started a thread named
> [MultiThreadedHttpConnectionManager cleanu
>
> p] but has failed to stop it. This is very likely to create a memory leak.
> Stack trace of thread:
>
>
>
> The rest of that log is either warnings about deprecated features or lines
> like these (which doesn't look fatal):
>
> 01-Jun-2017 05:57:35.306 WARNING [localhost-startStop-1]
> org.apache.solr.handler.component.SpellCheckComponent.inform No
> queryConverter defined, using default converter
>
>
>
> I made the mistake of turning on DEBUG logging. But after filtering out
> thousands of DEBUG messages I see:
>
> 2018-10-09 13:04:25,728 INFO org.dspace.usage.LoggerUsageEventListener @
> anonymous:session_id=7D74E0A56FFA3493875B4B5436B875C6:ip_addr=127.0.0.1:view_item:handle=11122/6045
>
> 2018-10-09 13:04:25,738 ERROR org.dspace.statistics.SolrLogger @
> org.apache.commons.httpclient.ProtocolException: The server
> scholarworks.alaska.edu failed to respond with a valid HTTP response
>
> org.apache.solr.client.solrj.SolrServerException:
> org.apache.commons.httpclient.ProtocolException: The server
> scholarworks.alaska.edu failed to respond with a valid HTTP response
>
>
>
> Perhaps Solr is trying to use HTTP while the server is configured for
> (mostly) HTTPS with a few exceptions. There was something a co-worker had
> added to the web.xml file
>
> to force HTTPS but I don't see it now. He might've removed it and put all
> that in the httpd configuration. If he didn't that might be the problem -
> the two of them fighting.
>
>
>
>
> On Tuesday, October 9, 2018 at 11:51:14 AM UTC-8, Tim Donohue wrote:
>
> Hi Walter,
>
> I don't think those "messages.xml" notices have anything to do with this
> Solr Statistics problem. That "messages.xml" file is not directly related
> to Solr. The XMLUI also looks for those files in several different
> locations, so if it doesn't find them in one place, it will look
> elsewhere. So, those log lines can likely be ignored.
>
>
>
> What you should be looking more closely at is whether any errors/warnings
> are occurring in the dspace.log files (or Tomcat logs) when you:
>
> (1) Access any Community/Collection/Item homepage on the site --- this
> should contact Solr and log a "view" of that Item
>
> (2) When you access the statistics page (that empty page may be throwing
> an error behind the scenes).
>
>
>
> Essentially look closely at the logs whenever you are performing tasks
> that should be logging "view" statistics to Solr, and also look closely in
> the Tomcat logs to be sure that the "/solr" webapp is deploying properly,
> without errors.
>
>
>
> - Tim
>
>
>
> On Tue, Oct 9, 2018 at 2:41 PM <wlruth...@alaska.edu> wrote:
>
>
>
> This might be the problem. In the latest cocoon log I saw lots of entries
> flash by that started with date/time like this:
>
> 2018-10-09 11:20:37,862 INFO org.apache.cocoon.i18n.XMLResourceBundle
>
> Then:
>
> - Bundle <file:///dspace/webapps/ROOT/i18n/aspects/EPerson/messages.xml>
> not loaded: Source URI not found
>
> - Bundle <resource://aspects/EPerson/i18n/messages.xml> not loaded: Source
> URI not found
>
> - Bundle <
> file:///dspace/webapps/ROOT/i18n/aspects/Administrative/messages.xml> not
> loaded: Source URI not found
>
> - Bundle <resource://aspects/Administrative/i18n/messages.xml> not loaded:
> Source URI not found
>
> - Bundle <
> file:///dspace/webapps/ROOT/i18n/aspects/SearchArtifacts/messages.xml>
> not loaded: Source URI not found
>
> - Bundle <resource://aspects/SearchArtifacts/i18n/messages.xml> not
> loaded: Source URI not found
>
> - Bundle <
> file:///dspace/webapps/ROOT/i18n/aspects/BrowseArtifacts/messages.xml>
> not loaded: Source URI not found
>
> - Bundle <resource://aspects/BrowseArtifacts/i18n/messages.xml> not
> loaded: Source URI not found
>
> - Bundle <
> file:///dspace/webapps/ROOT/i18n/aspects/ViewArtifacts/messages.xml> not
> loaded: Source URI not found
>
> - Bundle <resource://aspects/ViewArtifacts/i18n/messages.xml> not loaded:
> Source URI not found
>
> - Bundle <file:///dspace/webapps/ROOT/i18n/aspects/Versioning/messages.xml>
> not loaded: Source URI not found
>
> - Bundle <resource://aspects/Versioning/i18n/messages.xml> not loaded:
> Source URI not found
>
>
>
> The 'aspects' are something I've seen in the manual that's been added with
> the upgrade but I've done nothing to
>
> configure anything there.
>
>
>
> I started to say the messages.xml file exists but no, the one I've had to
> edit is in the i18n directory - the one in the
>
> error message doesn't exist in i18n/aspects/Versioning - the entire
> 'aspects' subdirectory doesn't exist at all.
>
> I could create the directories but can't populate them without knowing
> what should be in there. Where should it
>
> have come from? If fixing this doesn't require a scratch rebuild we might
> be able to quickly squash this bug.
>
>
>
> Walter R.
>
>
>
>
> On Tuesday, October 9, 2018 at 11:12:43 AM UTC-8, Tim Donohue wrote:
>
> Hi Walter,
>
>
>
> All I meant is that the "solr" webapp that DSpace creates needs to be
> available/deployed to Tomcat. So, for example, if Tomcat is running on
> http://localhost:8080, then Solr should be accessible on something like
> http://localhost:8080/solr/
>
>
>
> In other words, the only way DSpace can properly communicate with Solr (to
> send/query statistics) is if it's available in Tomcat. The full path to
> Solr in Tomcat should also be configured in your installed
> [dspace]/config/modules/solr-statistics.cfg:
> https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace/config/modules/solr-statistics.cfg#L12
>
>
>
> If DSpace is unable to find/communicate with Solr, you likely would see
> errors appearing in your logs.
>
>
>
> - Tim
>
>
>
> On Tue, Oct 9, 2018 at 2:04 PM <wlruth...@alaska.edu> wrote:
>
> Thank you Tim. I didn't notice anything in the logs that seemed to point
> to a problem with Solr
>
> or the statistics. I'll look again to make sure I haven't overlooked
> something. Also checking the
>
> troubleshooting page you linked.
>
>
>
> I'm not sure what you mean by the DSpace Solr webapp, *must* be installed
> into Tomcat. Are
>
> you talking about during the build it must be configured with Tomcat or
> that it is configured in
>
> the [dspace]/webapps/solr directory after DSpace has been built?
>
>
>
> Walter R.
>
>
>
>
> On Tuesday, October 9, 2018 at 10:28:53 AM UTC-8, Tim Donohue wrote:
>
> Hi Walter,
>
> I'd recommend checking your logs for any errors or warnings. We have a
> guide for doing so at:
>
> https://wiki.duraspace.org/display/DSPACE/Troubleshoot+an+error
>
>
>
> DSpace does *require* using Solr for Statistics. However, the required
> "solr" webapp is provided out-of-the-box with DSpace (it is built into the
> [dspace]/webapps/solr/ directory), so you do not need to install Apache
> Solr separately. That DSpace Solr webapp *must* be installed into Tomcat
> (alongside your UI, either XMLUI or JSPUI) for Statistics to work properly.
>
>
>
> Any errors that are occurring with accessing or logging statistics should
> be logged in your dspace.log file (or, occasionally, in the Tomcat logs).
>
>
>
> In the XMLUI, blank pages usually mean something went wrong. Most of the
> time, you should have more information in your logs. However, if no
> information is found there, it's always possible that the problem is in
> your *theme* (XSLTs or similar). So, if you get stuck, you may also want
> to try temporarily switching to a default DSpace theme, to ensure your
> custom theme is not causing issues.
>
>
>
> If you have more information to share, or start to figure out what might
> be to blame, please let us know on this mailing list. Currently, though,
> it doesn't look like we have enough information to provide help (unless
> someone else on this mailing list has seen this exact same behavior before).
>
>
>
> Tim
>
>
>
> On Mon, Oct 8, 2018 at 5:12 PM <wlruth...@alaska.edu> wrote:
>
>
>
> I'm still having problems with the statistics in DSpace. I have an older
> server running DSpace3.1 which is
>
> a "copy" of the original system. The statistics apparently haven't worked
> since the system moved. The 2nd
>
> system is running DSpace5.5. On both systems there is a "View Usage
> Statistics" link on the Home page
>
> but following the link gives a valid, live page but with no numbers. The
> Search and Workflow statistic links
>
> give identical error messages on both systems.
>
>
>
> I have gone through the manual and tried enabling all of the configuration
> parameters mentioned but with
>
> no luck. I even tried a few which didn't at first seem necessary but
> couldn't hurt. Still nothing.
>
>
>
> The manual says that DSpace uses Apache Solr and there is no need to
> download any separate software.
>
> But something isn't working. Do I really need to install and run Apache
> Solr? What I'm I misconfiguring?
>
>
>
> Does this look familiar to anyone?
>
>
>
> DSpace3.1 system: https://scholarworks.alaska.edu/statistics-home
> (may be behind firewall)
>
> DSpace5.5 system:
> https://dspace36a.library.uaf.edu/xmlui/statistics-home
>
>
>
> Thank you,
>
>
>
> Walter Rutherford
>
>
>
> --
> All messages to this mailing list should adhere to the DuraSpace Code of
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-tech...@googlegroups.com.
> To post to this group, send email to dspac...@googlegroups.com.
>
>
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>
> --
>
> Tim Donohue
> Technical Lead for DSpace & DSpaceDirect
> DuraSpace.org | DSpace.org | DSpaceDirect.org
>
> --
> All messages to this mailing list should adhere to the DuraSpace Code of
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-tech...@googlegroups.com.
> To post to this group, send email to dspac...@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>
> --
>
> Tim Donohue
> Technical Lead for DSpace & DSpaceDirect
> DuraSpace.org | DSpace.org | DSpaceDirect.org
>
> --
> All messages to this mailing list should adhere to the DuraSpace Code of
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-tech...@googlegroups.com.
> To post to this group, send email to dspac...@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>
> --
>
> Tim Donohue
> Technical Lead for DSpace & DSpaceDirect
> DuraSpace.org | DSpace.org | DSpaceDirect.org
>
> --
> All messages to this mailing list should adhere to the DuraSpace Code of
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-tech...@googlegroups.com.
> To post to this group, send email to dspac...@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> All messages to this mailing list should adhere to the DuraSpace Code of
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-tech...@googlegroups.com <javascript:>.
> To post to this group, send email to dspac...@googlegroups.com
> <javascript:>.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>
--
All messages to this mailing list should adhere to the DuraSpace Code of
Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
