Hi
It seems not to work in my case. We are using the solr php module for
talking to Solr. Currently we have 2 collections 'intradesk' and 'lvs'
for 10 solr hosts (shards: 5 - repl: 2). Because there is no more disc
space I created 6 new hosts for collection 'messages' (shards: 3 - repl: 2).
'intradesk + lvs':
solr01-dcg
solr01-gs
solr02-dcg
solr02-gs
solr03-dcg
solr03-gs
solr04-dcg
solr04-gs
solr05-dcg
solr05-gs
'messages':
solr06-dcg
solr06-gs
solr07-dcg
solr07-gs
solr08-dcg
solr08-gs
So when doing a select, I can talk to any host. When updating I must
talk to a host with at least 1 shard on it.
I created the new messages shard with the following command to get them
on the new hosts (06 -> 08):
http://solr01-dcg.intnet.smartbit.be:8983/solr/admin/collections?action=CREATE&name=messages&numShards=3&replicationFactor=2&collection.configName=smsc&createNodeSet=solr06-gs.intnet.smartbit.be:8983_solr,solr06-dcg.intnet.smartbit.be:8983_solr,solr07-gs.intnet.smartbit.be:8983_solr,solr07-dcg.intnet.smartbit.be:8983_solr,solr08-gs.intnet.smartbit.be:8983_solr,solr08-dcg.intnet.smartbit.be:8983_solr
They are all in the same config set 'smsc'.
Below is the code:
$client = new SolrClient(
array(
'hostname' => "solr01-dcg.intnet.smartbit.be
<http://solr01-dcg.intnet.smartbit.be:8983/solr/admin/collections?action=CREATE&name=messages&numShards=3&replicationFactor=2&collection.configName=smsc&createNodeSet=solr06-gs.intnet.smartbit.be:8983_solr,solr06-dcg.intnet.smartbit.be:8983_solr,solr07-gs.intnet.smartbit.be:8983_solr,solr07-dcg.intnet.smartbit.be:8983_solr,solr08-gs.intnet.smartbit.be:8983_solr,solr08-dcg.intnet.smartbit.be:8983_solr>",
'port' => "8983",
'login' => "***",
'password' => "***",
'path' => "solr/messages",
'wt' => "json"
)
);
$doc = new
SolrInputDocument();
$doc->addField('id', $uniqueID);
$doc->addField('smsc_ssid', $ssID);
$doc->addField('smsc_module', $i['module']);
$doc->addField('smsc_modulekey', $i['moduleKey']);
$doc->addField('smsc_courseid', $courseID);
$doc->addField('smsc_description', $i['description']);
$doc->addField('smsc_content', $i['content']);
$doc->addField('smsc_lastdate', $lastdate);
$doc->addField('smsc_userid', $userID);
$client->addDocument($doc);
The exception I get look like this:
exception 'SolrClientException' with message 'Unsuccessful update
request. Response Code 200. (null)'
Nothing special to find in the solr log.
Any idea?
Arkadi
On 04/24/2013 08:43 PM, Mark Miller wrote:
Sorry - need to correct myself - updates worked the same as read requests -
they also needed to hit a SolrCore in order to get forwarded to the right node.
I was not thinking clearly when I said this applied to just reads and not
writes. Both needed a SolrCore to do their work - with the request proxying,
this is no longer the case, so you can hit Solr instances with no SolrCores or
with SolrCores that are not part of the collection you are working with, and
both read and write side requests are now proxied to a suitable node that has a
SolrCore that can do the search or forward the update (or accept the update).
- Mark
On Apr 23, 2013, at 3:38 PM, Mark Miller <markrmil...@gmail.com> wrote:
We have a 3rd release candidate for 4.3 being voted on now.
I have never tested this feature with Tomcat - only Jetty. Users have reported
it does not work with Tomcat. That leads one to think it may have a problem in
other containers as well.
A previous contributor donated a patch that explicitly flushes a stream in our
proxy code - he says this allows the feature to work with Tomcat. I committed
this feature - the flush can't hurt, and given the previous contributions of
this individual, I'm fairly confident the fix makes things work in Tomcat. I
have no first hand knowledge that it does work though.
You might take the RC for a spin and test it our yourself:
http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/
- Mark
On Apr 23, 2013, at 3:20 PM, Furkan KAMACI <furkankam...@gmail.com> wrote:
Hi Mark;
All in all you say that when 4.3 is tagged at repository (I mean when it is
ready) this feature will work for Tomcat too at a stable version?
2013/4/23 Mark Miller <markrmil...@gmail.com>
On Apr 23, 2013, at 2:49 PM, Shawn Heisey <s...@elyograg.org> wrote:
What exactly is the 'request proxying' thing that doesn't work on
tomcat? Is this something different from basic SolrCloud operation where
you send any kind of request to any server and they get directed where they
need to go? I haven't heard of that not working on tomcat before.
Before 4.2, if you made a read request to a node that didn't contain part
of the collection you where searching, it would return 404. Write requests
would be forwarded to where they belong no matter what node you sent them
to, but read requests required that node have a part of the collection you
were accessing.
In 4.2 we added request proxying for this read side case. If a piece of
the collection you are querying is not found on the node you hit, a simple
proxy of the request is done to a node that does contain a piece of the
collection.
- Mark
