After upgrading to Solr 4.2.1, deploying the Solr war file to GlassFish version 3.1.1 results in the following error:
2013-04-09 10:45:06,144 [main] ERROR org.apache.solr.servlet.SolrDispatchFilter - Could not start Solr. Check solr/home property and the logs
2013-04-09 10:45:06,224 [main] ERROR org.apache.solr.core.SolrCore - null:org.apache.http.conn.ssl.SSLInitializationException: Failure initializing default system SSL context
at org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:368)
at org.apache.http.conn.ssl.SSLSocketFactory.getSystemSocketFactory(SSLSocketFactory.java:204)
at org.apache.http.impl.conn.SchemeRegistryFactory.createSystemDefault(SchemeRegistryFactory.java:82)
at org.apache.http.impl.client.SystemDefaultHttpClient.createClientConnectionManager(SystemDefaultHttpClient.java:118)
at org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:466)
at org.apache.solr.client.solrj.impl.HttpClientUtil.setMaxConnections(HttpClientUtil.java:179)
Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:772)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
at java.security.KeyStore.load(KeyStore.java:1214)
at org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:281)
at org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:366)
... 50 more
Caused by: java.security.UnrecoverableKeyException: Password verification failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:770)
... 54 more
It seems like people have had this problem when using Solr version 4.2 and the bug fix release 4.2.1 was supposed to fix it (?). Any pointers will be greatly appreciated.
Had the same problems a few days ago. Solved it by downgrading to solr 4.1.0. But there is a solution (found it by googling my personally well known search terms once again ;) Just add two JVM options. Start glassfish with:
asadmin start-domain
and enter:
asadmin create-jvm-options -- -Djavax.net.ssl.keyStorePassword=changeit
asadmin create-jvm-options -- -Djavax.net.ssl.trustStorePassword=changeit
Don't forget to restart glassfish:
asadmin restart-domain
Tried it for myself and works like a charm. Obviously this is working only if you never changed those passwords before.
Related
I can't run payara 4.1.2.181 with java 7 (Orracle jdk 1.7.0_80).
I have no problem with java 8 and the previous build of Payara (4.1.2.172) runs fine with Java 7. I couldn't find any mention about stopping support for Java 7 in this version.
The error I got is this one (server.log):
Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle fish.payara.microprofile.fault-tolerance.microprofile-fault-tolerance [149]: Unable to resolve 149.0: missing requirement [149.0] osgi.wiring.package; (&(osgi.wiring.package=org.eclipse.microprofile.config)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve 223.0: missing requirement [223.0] osgi.ee; (&(osgi.ee=JavaSE)(version=1.8))]
Co you have any idea how to solve it?
Regards
Piotr
Payara stopped supporting JDK7 for public releases in 4.1.2.173, as explained in this blog post. It is still available for paying customers until 2023. So either upgrade to JDK8 or get Payara support.
I've installed Solr on my Ubuntu to this path
/opt/solr/solr-4.10.2
After installing I started Solr:
sudo bin/solr start from /opt/solr/solr-4.10.2 directory
As I can understand it started successfully
Waiting to see Solr listening on port 8983 [/]
Started Solr server on port 8983 (pid=8385). Happy searching!
But when I try to get to admin page
http://localhost:8983/solr
I got 404 error:
HTTP ERROR: 404
Problem accessing /solr. Reason:
Not Found
Powered by Jetty://
Do you have any suggestion what's going wrong and where to look in order to fix this problem?
Since this error can be caused by a lot of things, you need to access the log file and debug the execution.
First of all, open your Node log file, located in /opt/solr/solr-4.10.2/node1/log and look for something weird (Shift+F for Errors).
Generally, this error occurs when you have a mismatch between the Solr required Java JDK and your current Java JDK.
When I had this problem, I found in the log file the following error message java.lang.UnsupportedClassVersionError: org/apache/solr/servlet/SolrDispatchFilter : Unsupported major.minor version 51.0 and realized the problem was the java version.
To solve this, try to change the current JDK, using the command sudo update-alternatives --config javac.
If the error still occurs, try to uninstall all unused JDK's, because Solr is getting the wrong path.
The final solution to this issue is to open the file /opt/solr/solr-4.10.2/solar.in.sh and edit the SOLR_JAVA_HOME, writing the right JDK path (e.g /usr/lib/jvm/java-1.7.0)
Disclosure: the secret is look in the log file and figure out what is causing the issue.
Cheers.
try:
http://localhost:8983/solr/index.html
[solr's web.xml]
<servlet>
<servlet-name>LoadAdminUI</servlet-name>
<servlet-class>org.apache.solr.servlet.LoadAdminUiServlet</servlet-class>
I try to install SOLR 3.6.0 on a Websphere Portal 7.0. It gives me the following messages in the log:
java.lang.NoSuchMethodError: org/apache/lucene/store/FSDirectory.open(Ljava/io/File;)Lorg/apache/lucene/store/FSDirectory;
at org.apache.solr.core.StandardDirectoryFactory.open(StandardDirectoryFactory.java:33)
After some research I found some lucene which comes with the Portal server.
This is the place, where it's found:
/opt/IBM/WebSphere/PortalServer/prereq/prereq.lucene/shared/app/lucene.jar.
I suspect that this messed up the classloader. I have changed the classloader policy of the application :(
Have anyone experienced the same and did you find a work around?
Thats in advance for your answers
Cheers,
-Fred
(This is a cross-post from servefault. I'm posting it here because no one answered my post there, and I feel that this sort of hits an awkward space half-way between both stackoverflow and serverfault.)
I have modified the example project included with Solr for my needs (removing things like the example stopwords and defining my own schema). Running this project on my mac, everything works fine: I can start Jetty and run search queries. But when I push the project out to a Debian system, I get this error when I try to do search queries:
HTTP ERROR: 503
SERVICE_UNAVAILABLE RequestURI=/solr
Powered by jetty://
The request log shows that a request was made:
10.10.124.14 - - [22/06/2010:22:34:52 +0000] "GET /solr
HTTP/1.1" 503 1311
No error log is produced (at least not on in the ./logs directory).
I have tried to run this project both on openjdk and the Sun JRE. Both started jetty fine, but produced the same error when searching. I am running Debian 9.0.4.
The issue is probably that the datastore in Debian is /var/lib/solr/data and you need to set that line in your version solrconfig.xml instead of the default which is in the base directory /usr/share/solr/ which could be a read only file system.
I've packaged the last solr version in Debian Testing. It seems, that there is some error in the solr configuration so that jetty starts, but it can't start the solr servlet. You must look in the jetty error log to find the reason.
There's lack of manpower in Java Packaging for Debian, so it may well be that there is an error in the solr-jetty package.
The solr-jetty package in Debian stable doesn't work as I recall. Please try from Debian testing!
If you indeed find an error, please don't use random forums but post a bug on bugs.debian.org!
Success!
I have an issue loading xdebug in apache server.
Here are my settings:
Apache 2.2.11
MySQL 5.1.36
PHP 5.2.0
Windows 7
Wampserver 2.0
php -i and php -m show that the xdebug module php_xdebug-2.1.0RC1-5.2-vc6.dll is installed.
However phpinfo() does not show that xdebug is installed. I have tried starting apache as a service, through the Wampserver UI, and by running httpd directly (as administrator) and I have checked permissions on the php_xdebug-2.1.0RC1-5.2-vc6.dll file.
There are no warnings in the logs. In the apache error log I get:
[Thu Jun 24 11:20:55 2010] [notice] Apache/2.2.11 (Win32) PHP/5.2.0 configured -- resuming normal operations
Has anyone any ideas?
Thank you,
John
I already do like you said but nothing happens
Using WAMPSERVER 2.1 , php_xdebug-2.1.0-5.3-vc6.dll (however I renamed it becoming php_xdebug.dll)
In php.ini, I also modified as instructions
extension=php_xdebug.dll
...
zend_extension = "C:/wamp/bin/php/php5.3.3/ext/php_xdebug.dll"
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.idekey="netbeans-xdebug"
After starting the server again, there are no error in Apache log, everything seems work normal.Still do not see any information about xdebug from phpinfo. I totally gave up :(
Any ideas for my case, appreciated that.
I solved my issue as I was using wampserver2.0 and naively assumed I could use c:\wamp\bin\php\php{version#}\php.ini to affect my configuration.
In actual fact one must use c:\wamp\apache\Apache{version#}\bin\php.ini to configure php on the wamp server.
Hope this helps anyone else who might one day tear their hair out over this.
John