on a quick glance, and not having tried this myself...
this seems wrong. You're setting a URL parameter "db":
params.set("db","/dataimport");
that's equivalent to a URL like
http://localhost:8983/solr&db=/dataimport
you'd want:
http://localhost:8983/solr/db/dataimport?command=full-import
I think you want to set your url for your HTTPClient to
the full solr path to dataimport handler, i.e something like
...solr/collection_or_core/dataimport
then set the params for dataimport handler like you are, i.e.:
params.set("command", "full-import");
Best,
Erick
On Sat, Nov 26, 2016 at 11:03 AM, Marek Ščevlík
<mscev...@codenameprojects.com> wrote:
> Actually to be honest I realized that I only needed to trigger a data
> import handler from a jar file. Previously this was done in earlier
> versions via the SolrServer object. Now I am thinking if this is OK?:
>
> String urlString1 = "http://localhost:8983/solr/";;
> SolrClient solr1 = new HttpSolrClient.Builder(urlString).build();
>
> ModifiableSolrParams params = new ModifiableSolrParams();
> params.set("db","/dataimport");
> params.set("command", "full-import");
> System.out.println(params.toString());
> QueryResponse qresponse1 = solr1.query(params);
>
> System.out.println("response = " + qresponse1);
>
> Output i get from this is: response =
> {responseHeader={status=0,QTime=0,params={wt=javabin,version=2,db=/dataimport,command=full-import}},response={numFound=0,start=0,docs=[]}}
>
> There is a core db which come with the examples in solr 6.3 package. It is
> loaded. From web ui admin I can operate it a run the dih reindex process.
>
> I wonder whether this could work ? What do you think? I am trying to call
> DIH whilst solr is running. This code is in a separate jar file that is run
> besides solr instance.
>
> This so far is not working for me. And I wonder why? What do you think?
> Should this work at all? OR perhaps someone else could help out.
>
>
> Thanks anyone for any help.
> ========================
>
> 2016-11-25 19:50 GMT+01:00 Marek Ščevlík <mscev...@codenameprojects.com>:
>
>> I forgot to mention I am creating a jar file beside of a running solr 6.3
>> instance to which I am hoping to attach with java via the
>> SolrDispatchFilter to get at the cores and so then I could work with data
>> in code.
>>
>>
>> 2016-11-25 19:31 GMT+01:00 Marek Ščevlík <mscev...@codenameprojects.com>:
>>
>>> Hi Daniel. Thanks for a reply. I wonder is it now still possibly with
>>> release of Solr 6.3 to get hold of a running instance of the jetty server
>>> that is part of the solution? I found some code for previous versions where
>>> it was captured with this code and one could then obtain cores for a
>>> running solr instance ...
>>>
>>> SolrDispatchFilter solrDispatchFilter = (SolrDispatchFilter) jetty
>>>
>>> .getDispatchFilter().getFilter();
>>>
>>>
>>> I was trying to implement it this way but that is not working out very
>>> well now. I cant seem to get the jetty server object for the running
>>> instance. I tried several combinations but none seemed to work.
>>>
>>> Can you perhaps point me in the right direction?
>>>
>>> Perhaps you may know more than I do at the moment.
>>>
>>>
>>> Any help would be great.
>>>
>>>
>>> Thanks a lot
>>> Regards Marek Scevlik
>>>
>>>
>>>
>>> 2016-11-18 15:53 GMT+01:00 Davis, Daniel (NIH/NLM) [C] <
>>> daniel.da...@nih.gov>:
>>>
>>>> Marek,
>>>>
>>>> I've wanted to do something like this in the past as well. However, a
>>>> rewrite that supports the same XML syntax might be better. There are
>>>> several problems with the design of the Data Import Handler that make it
>>>> not quite suitable:
>>>>
>>>> - Not designed for Multi-threading
>>>> - Bad implementation of XPath
>>>>
>>>> Another issue is that one of the big advantages of Data Import Handler
>>>> goes away at this point, which is that it is hosted within Solr, and has a
>>>> UI for testing within the Solr admin.
>>>>
>>>> A better open-source Java solution might be to connect Solr with Apache
>>>> Camel - http://camel.apache.org/solr.html.
>>>>
>>>> If you are not tied absolutely to pure open-source, and freemium
>>>> products will do, then you might look at Pentaho Spoon and Kettle.
>>>> Although Talend is much more established in the market, I find Pentaho's
>>>> XML-based ETL a bit easier to integrate as a developer, and unit test and
>>>> such. Talend does better when you have a full infrastructure set up, but
>>>> then the attention required to unit tests and Git integration seems over
>>>> the top.
>>>>
>>>> Another powerful way to get things done, depending on what you are
>>>> indexing, is to use LogStash and couple that with Document processing
>>>> chains. Many of our projects benefit from having a single RDBMS view,
>>>> perhaps a materialized view, that is used for the index. LogStash does
>>>> just fine here, pulling from the RDBMS and posting each row to Solr. The
>>>> hierarchical execution of Data Import Handler is very nice, but this can
>>>> often be handled on the RDBMS side by creating a view, maybe using
>>>> functions to provide some rows. Many RDBMS systems also support
>>>> federation and the import of XML from files, so that this brings XML
>>>> processing into the picture.
>>>>
>>>> Hoping this helps,
>>>>
>>>> Dan Davis, Systems/Applications Architect (Contractor),
>>>> Office of Computer and Communications Systems,
>>>> National Library of Medicine, NIH
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Marek Ščevlík [mailto:mscev...@codenameprojects.com]
>>>> Sent: Friday, November 18, 2016 9:29 AM
>>>> To: solr-user@lucene.apache.org
>>>> Subject: Data Import Request Handler isolated into its own project - any
>>>> suggestions?
>>>>
>>>> Hello. My name is Marek Scevlik.
>>>>
>>>>
>>>>
>>>> Currently I am working for a small company where we are interested in
>>>> implementing your Sorl 6.3 search engine.
>>>>
>>>>
>>>>
>>>> We are hoping to take out from the original source package the Data
>>>> Import Request Handler into its own project and create a usable .jar file
>>>> out of it.
>>>>
>>>>
>>>>
>>>> It should then serve as tool that would allow to connect to a remote
>>>> server and return data for us to our other application that would use the
>>>> returned data.
>>>>
>>>>
>>>>
>>>> What do you think? Would anything like this possible? To isolate out the
>>>> Data Import Request Handler into its own standalone project?
>>>>
>>>>
>>>>
>>>> If we could achieve this we won’t mind to share with the community this
>>>> new feature.
>>>>
>>>>
>>>>
>>>> I realize this is a first email and may lead into several hundreds so
>>>> for the start my request is very simple and not so high level detailed but
>>>> I am sure you realize it may lead into being quite complex.
>>>>
>>>>
>>>>
>>>> So I wonder if anyone replies.
>>>>
>>>>
>>>>
>>>> Thanks a lot for any replies and further info or guidance.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Regards Marek Scevlik
>>>>
>>>
>>>
>>
