Backwards compatibility issue

[Karel Vervaeke <ka...@ngdata.com>]

IIUC A Solrj 4.4 client should be able to speak to a Solr 4.6 cloud
instance.
Assuming this is correct there's an issue because of a change in
clusterstate.json:

In a 4.4 cloud server clusterstate.json would contain `router: "implicit"`
In a 4.6 cloud server clusterstate.json contains `router:
{"name":"implicit"}`.

Because of this a 4.4 solrj client will look up a router (in
DocRouter.java) using the key `{"name":"implicit"}` instead of just
`implicit`.
Is there a way around this that does not involve upgrading the solrj client?

Regards,
Karel

Re: Backwards compatibility issue

[Karel Vervaeke <ka...@ngdata.com>]

Thanks for your feedback. Upgrading SolrJ is going to be a bit difficult
(because it's tied in with a framework which is only partially owned by
us), so we'll just have to find another way to deal with it.

Karel


On Fri, Dec 13, 2013 at 7:28 PM, Shawn Heisey <so...@elyograg.org> wrote:

> On 12/13/2013 7:40 AM, Karel Vervaeke wrote:
> > IIUC A Solrj 4.4 client should be able to speak to a Solr 4.6 cloud
> > instance.
> > Assuming this is correct there's an issue because of a change in
> > clusterstate.json:
> >
> > In a 4.4 cloud server clusterstate.json would contain `router:
> "implicit"`
> > In a 4.6 cloud server clusterstate.json contains `router:
> > {"name":"implicit"}`.
> >
> > Because of this a 4.4 solrj client will look up a router (in
> > DocRouter.java) using the key `{"name":"implicit"}` instead of just
> > `implicit`.
> > Is there a way around this that does not involve upgrading the solrj
> client?
>
> Although the committers do try really really hard to maintain
> cross-version compatibility between SolrJ and Solr versions, sometimes
> changes must be made that break that compatibility, either to support
> critical new functionality or because of bugs or situations that were
> not anticipated.  SolrCloud technology is relatively new, so things are
> changing quickly to accommodate new functionality and fix stability
> problems.
>
> SOLR-4221 made this change (released in version 4.5.0) so that more than
> one property could be assigned to 'router' because more information is
> sometimes needed.
>
> https://issues.apache.org/jira/browse/SOLR-4221
>
> One of the commits made on this issue was to allow a newer SolrJ to talk
> to an older cluster with the previous clusterstate router format.  If
> for some reason you need to run different SolrJ and Solr versions, it is
> almost always better to have a newer SolrJ than Sol
>
> Thanks,
> Shawn
>
>

Re: Backwards compatibility issue

[Shawn Heisey <so...@elyograg.org>]

On 12/13/2013 7:40 AM, Karel Vervaeke wrote:
> IIUC A Solrj 4.4 client should be able to speak to a Solr 4.6 cloud
> instance.
> Assuming this is correct there's an issue because of a change in
> clusterstate.json:
> 
> In a 4.4 cloud server clusterstate.json would contain `router: "implicit"`
> In a 4.6 cloud server clusterstate.json contains `router:
> {"name":"implicit"}`.
> 
> Because of this a 4.4 solrj client will look up a router (in
> DocRouter.java) using the key `{"name":"implicit"}` instead of just
> `implicit`.
> Is there a way around this that does not involve upgrading the solrj client?

Although the committers do try really really hard to maintain
cross-version compatibility between SolrJ and Solr versions, sometimes
changes must be made that break that compatibility, either to support
critical new functionality or because of bugs or situations that were
not anticipated.  SolrCloud technology is relatively new, so things are
changing quickly to accommodate new functionality and fix stability
problems.

SOLR-4221 made this change (released in version 4.5.0) so that more than
one property could be assigned to 'router' because more information is
sometimes needed.

https://issues.apache.org/jira/browse/SOLR-4221

One of the commits made on this issue was to allow a newer SolrJ to talk
to an older cluster with the previous clusterstate router format.  If
for some reason you need to run different SolrJ and Solr versions, it is
almost always better to have a newer SolrJ than Sol

Thanks,
Shawn