Anyone an idea how to debug this?
Thx!
On 04/25/2013 09:18 AM, Arkadi Colson wrote:
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
