I have three solr 3.4.0 indexes that I want to merge, after searching I've found that there are two ways to do it:
Using Lucene Merge tool.
Merging through core admin
I am using lucene 3.4.0 and running following command:
java -cp d:/lucene/lucene-core-3.4.0.jar:./contrib/misc/lucene-misc-3.4.0.jarorg/apache/lucene/misc/IndexMergeTool ./newindex ./app1/solr/data/index ./app2/solr/data/index
but unfortunately it gives me following exception:
Exception in thread "Main Thread" java.lang.NoClassDefFoundError:
org/apache/lucene/misc/IndexMergeTool
Can anybody help me with this?
Couple of things :-
./contrib/misc/lucene-misc-3.4.0.jar
Are you running it from the correct directory for it to find the jar. Why not use full path ?
You are using :(colon) as jar classpath separator, and using windows it should be ; (semi-colon)
Also -
If you already have Solr running with the Solr indexes ready, I would recommend you to use the second option - merging through Solr Admin.
This is more easy to use with direct http interface without any additional overheads and would work out of the box.
I solved this particular problem by creating a new java application in net beans 7.1 and adding both the jar files as library. and inside my new application's main method i have called
IndexMergeTool.main
and pass all command line arguments to above mentioned method.
Regards
Ahsan
Related
I want to use JavaMelody to monitor the SQL requested by a Glassfish Application Server. There are step-by-step instructions on https://github.com/javamelody/javamelody/wiki/UserGuideAdvanced#monitoring-of-sql-requests-and-of-jdbc-connections-in-glassfish-v3
I followed the instructions (I didn't download javamelody-objectfactory.jar but used javamelody-core-1.54.0.jar instead) and I get this error when clicking on the refresh button (javamelody web page) :
server.log :
exception while collecting data
java.lang.NoClassDefFoundError: org/jrobin/core/RrdException
at net.bull.javamelody.Collector.getCounterJRobin(Collector.java:836)
at net.bull.javamelody.Collector.collectJRobinValues(Collector.java:489)
...
any idea how to resolve this ?
jrobin-1.5.9.1.jar is installed in the lib folder of glassfish (and in my ear project).
thanks !
javamelody-objectfactory.jar (java source included in the jar) and javamelody-core jar file are absolutely different things. The first is to make the datasource monitorable in Glassfish and the second is the monitoring tool itself.
First fix the exception. You should probably put javamelody-core jar and jrobin jar files in your ear project (and not one in lib folder of Glassfish and one in ear).
Then if the monitoring reports don't include SQL monitoring for the datasource declared in Glassfish, use the javamelody-objectfactory.jar including all steps as said in the doc.
After recent migration from HBase 0.94.13 to HBase 0.98.12 my code is failing to execute.
I am simply trying to connect to a table via dependent jar file developed by another team who uses Spring HbaseTemplate. I have manually placed all the required jar files for executing the code including hbase-client-0.98.12-mapr-1506.jar (we have MapR distribution).
I am receiving the following error:
Caused by: java.lang.NoClassDefFoundError: org/apache/hadoop/hbase/filter/WritableByteArrayComparable
It seems to be occuring because HBase 0.96.x WritableByteArrayComparable has been renamed to ByteArrayComparable.
How can I make the old code work again?
I was able to make it work by keeping the old jar hbase-0.94.9-mapr-1308 in the classpath. It was a dirty fix but it did the job.
The other team whose dependent jar I was using to connect to M7, finally updated their code and now things are back to normal again. Thanks.
I am using Behat and JIRA together to run automated tests. Currently I am able to run a single JIRA issue using:
$ bin/behat jira:ISSUE_NUMBER
In order to this, I am using the JIRA extension for Behat (http://extensions.behat.org/jira-extension/)
However, I am looking for a way to run a group of tests on my JIRA account. I need this to work similar to the #tags in behat.
Any help would be greatly appreciated.
Thanks,
Girish Kini
This is currently not possible. After research, I have learnt that this feature is currently not supported by the jira extension. In the interim, try adding support for a comma separated list, eg jira:issue-1,issue-2,etc-n via the FeatureLoaderService.php.
sources: Anthon Pang via vipsoft/JiraExtension [ GitHub ]
You could create a version that included all the tickets that you wanted to run. Then in your behat.yml file specify that version using jql. Afterwhich you can run the following command.
php bin/behat http://myserver.com:8080/
I was trying to install Apache Solr 4.0.0 with apache Tomcat, but it is giving an error like this:
SolrCore Initialization Failures
collection1: java.io.IOException:java.io.IOException: Can't find resource 'solrconfig.xml' in classpath or 'solr\collection1\conf/', cwd=C:\apps\tomcat-solr\apache-tomcat-7.0.35\bin
There are no SolrCores running.
Using the Solr Admin UI currently requires at least one SolrCore.
After this I have installed apache solr 3.6.2 and it working perfectly well. I still cannot understand why i am not able to use solr 4.0.0 with the same server configuration.
I hope you will be able to tell me the mistake i have committed.
The directory structure changed in Solr 4.0. Have a look at the one in the example/solr directory. You will see that Solr 4 now has collection1 directory inside that and conf directory is now one level lower inside that. That's basically what the error message said.
If you don't like that, I think you can change it by putting solr.xml with the single core definition in it and directory paths setup the way you like it.
I have a few EJBs compiled with Weblogic's EJBC complient with Weblogic 9.2.1.
Our customer uses Weblogic 9.2.3.
During server start Weblogic gives the following message:
<BEA-010087> <The EJB deployment named: YYY.jar is being recompiled within the WebLogic Server. Please consult the server logs if there are any errors. It is also possible to run weblogic.appc as a stand-alone tool to generate the required classes. The generated source files will be placed in .....>
Consequently, server start takes 1.5 hours instead of 20 min. The next server start takes exactly the same time, meaning Weblogic does not cache the products of the recompilation. Needless to say, we cannot recompile all our EJBs to 9.2.3 just for this specific customer, so we need an on-site solution.
My questions are:
1. Is there any way of telling Weblogic to leave those EJB jars as they are and avoid the re-compilation during server start?
2. Can I tell Weblogic to cache the recompiled EJBs to avoid prolonged restarts?
Our current workaround was to write a script that does this recompilation manually before the EAR's creation and deployment (by simply running java weblogic.appc <jar-name>), but we would rather avoid this solution being used in production.
I FIXED this problem by spending a great deal of time researching
and decompiling some classes.I encountered this when migrating from weblogic8 to 10
by this time you might have understood the pain in dealing with oracle weblogic tech support.
unfortunately they did not have a server configuration setting to disable this
You need to do 2 things
Step 1.You if you open the EJB jar files you can see
ejb-jar.xml=3435671213
com.mycompany.myejbs.ejb.DummyEJBService=2691629828
weblogic-ejb-jar.xml=3309609440
WLS_RELEASE_BUILD_VERSION_24=10.0.0.0
you see these hascodes for each of your ejb names.Make these hadcodes zero.
pack the jar file and deploy it on server.
com.mycompany.myejbs.ejb.DummyEJBService=0
weblogic-ejb-jar.xml=0
This is just a Marker file that weblogic.appc keeps in each ejb jar to trigger the recompilation
during server boot up.i automated this process of making these hadcodes to zero.
This hashcodes remain the same for each ejb even if you execute appc for more than once
if you add a new EJB class or delete a class those entries are added to this marker file
Note 1:
how to get this file?
if you open domains/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX
you will see this file for each ejb.weblogic makes the hashcodes to zero after it recompiles
Note 2:
When you generate EJB using appc.generate them to a exploded directory using -output C:\myejb
instead of C:\myejb.jar.This way you can play around with the marker file
Step2.
Also you need a PATCH from weblogic.When you install the patch you see some message like this
"PATH CRXXXXXX installed successfully.Eliminate EJB recomilation for appc".
i dont remember the patch number but you can request weblogic for that.
You need to use both steps to fix the problem.The patch fixes only part of the problem
Goodluck!!
cheers
raj
the Marker file in EJBs is WL_GENERATED
Just to update the solution we went with - eventually we opted to recompile the EJBs once at the Customer's site instead of messing with the EJBs' internal markers (we don't want Oracle saying they cannot support problems derived from this scenario).
We created two KSH scripts - the first iterates over all the EJB jars, copies them to a temp dir and then re-compiles them in parallel by running several instances of the 2nd script which does only one thing: java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1 (With error handling of course :))
This solution reduced compilation time from 70min to 15min. After this we re-create the EAR file and redeploy it with the new EJBs. We do this once per several UAT environment creations, so we save quite a lot of time here (55min X num of envs per drop X num of drops)