: Below is my solr.xml configuration, and already set persistent to true.
...
: Then publish 1 record to test1, and query. it's ok now.
Ok, first off -- please provide more details on how exactly you are
running Solr. Your initial email said...
>>> In Solr 3.6, core swap function works good. After switch to use Solr 4.0
>>> Beta, and found it doesn't work well.
...but based on your solr.xml file and your logs, it appears you are now
trying to use some of the ZooKeeper/SolrCloud features that didn't even
exist in Solr 3.6, so it's kind of an apples to oranges comparison. i'm
pretty sure that for a simple multicore setup, SWAP still works exactly as
it did in Solr 3.6.
Wether SWAP works with ZooKeeper/SolrCloud is something i'm not really
clear on -- mainly because i'm not sure what it should mean conceptually.
Should the two SolrCores swap which collections they are apart of? what
happens if the doc->shard assignment for the two collections means the
same docs woulnd't wind up im those SolrCores? what if the SolrCores are
two different shards of the same collection befor teh SWAP?
FWIW: It wasn't clear from your messsage *how* you had your SolrCloud
system setup, but it appears from your pre-swap log messages that you are
running a single node, so I tried to reproduce the behavior you were
seeing by seting up a solr home dir like you described, and then
running...
java -Dsolr.solr.home=swap-test/ -DzkRun -Dbootstrap_conf=true -DnumShards=1
-jar start.jar
...because that was my best guess as to what you were running. But even
then i couldn't get the behavior you described after the swap...
: And found the shardurl is different with the log which search before swap.
: It’s shard.url=host1:18000/solr/test1-ondeck/| host1:18000/solr/test1/.
...what i observed after the swap, is that it apperaed as if hte SWAP had
no effect to client requests, because a client request to
"/solr/test1/select?q=*:*" was distributed under the covers to
"/solr/test1-ondeck/..." which is the new name for the core where the doc
had been indexed...
Sep 21, 2012 12:03:32 PM org.apache.solr.core.SolrCore execute
INFO: [test1-ondeck] webapp=/solr path=/select
params={distrib=false&wt=javabin&rows=10&version=2&df=text&fl=id,score&shard.url=frisbee:8983/solr/test1-ondeck/&NOW=1348254212677&start=0&q=*:*&isShard=true&fsv=true}
hits=1 status=0 QTime=0
Sep 21, 2012 12:03:32 PM org.apache.solr.core.SolrCore execute
INFO: [test1-ondeck] webapp=/solr path=/select
params={df=text&shard.url=frisbee:8983/solr/test1-ondeck/&NOW=1348254212677&q=*:*&ids=SOLR1000&distrib=false&isShard=true&wt=javabin&rows=10&version=2}
status=0 QTime=0
Sep 21, 2012 12:03:32 PM org.apache.solr.core.SolrCore execute
INFO: [test1] webapp=/solr path=/select params={q=*:*} status=0 QTime=10
...I'm guessing this behavior is because nothing in the SWAP call bothered
to tell ZK that these two SolrCores swaped names, so when asking to query
the "test1" collection, ZK says "ok, well the name of the core that's part
of that collection is test1-ondeck" and that's where the query was routed.
I only saw behavior similar to what you described (of the "shard.url"
refering to both SolrCores) after i restarted solr -- presumably because
as the solrCores started up, they both notified ZK about their existence,
and said what collection they (thought they) are a part of, but ZK also
already thinks they are each a part of a differet collection as well
(because nothing bothered to tell ZK otherwise).
So the long and short of it seems to be...
* CoreAdminHandler's SWAP is poorly defined if you are using SolrCloud
(most likely: so is RENAME and ALIAS) - i've opened SOLR-3866.
* This doesn't seem like a regression bug from Solr 3.6, because as
far as i can tell SWAP still works as well as it did in 3.6.
-Hoss
