You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by "Lee, Peter" <Pe...@proquest.com> on 2013/05/12 05:36:04 UTC
Looking to see if solrj 3.5 could be used with solr server 4.2.1
I've reviewed all of the release notes and we've been doing testing to see if solrj that came with solr 3.5 would work with solr server 4.2.1. We are not using any of the new features of 4.2.1...we upgraded purely for the improved performance and much smaller memory footprint of the indexes. While I have not identified anything in the release notes that looks like a deal breaker, I also realize that the powers that be may be thinking that this is such a no brainer question (why would ANYONE want to use solrj 3.5 with solr 4.2.1) that it simply was assumed obvious and did not need stating.
Well, we have a unique business/technical case that involves other applications, other platforms, timing and resource constraints, etc. Since we've noticed that in the simple search cases solrj 3.5 DOES work with solr 4.2.1 (obviously the new features do not...but we are not using the new features) we've opted to investigate this further. However, if anyone knows definitively that this WON'T work I'd appreciate a heads-up on it as you could save us a lot of time.
Since I know someone is going to ask "why do you want to do that"...I'll state up front that we DON'T want to do that. Unfortunately we live in a non-perfect world and we have some very specific (if not weird) project and technical constraints that could be temporarily mitigated if we could get this to work for a short period of time. Because the nature of these constraints are so project-specific (and somewhat involved), I won't be going into any details here. We are well aware of the fact that this would be a sub-optimal solution...but it turns out to be worth our time to at least investigate it as a stop-gap measure.
If you have any information regarding whether or not this might work (as in "yeah, we did that and it worked okay"...or..."no, that won't work because protocol XYZ changed between versions and <yada,yada,yada>") I would appreciate it. As stated above, simple cases using both exact match and analyzed fields have been shown to work. We are already investigating the more involved cases, but I figured it wouldn't hurt to ask for the input of the solr community.
With much appreciation,
Peter S. Lee
Software Development Lead
ProQuest
789 E. Eisenhower Parkway
Ann Arbor, MI, 48106-1346
USA
734-761-4700 x72025
peter.lee@proquest.com
www.proquest.com
ProQuest...Start here
InformationWeek 500 Top Innovator<http://www.proquest.com/en-US/aboutus/pressroom/09/20090922.shtml>
Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Posted by Shawn Heisey <so...@elyograg.org>.
On 5/11/2013 11:22 PM, Shawn Heisey wrote:
> Initial note: There might be a showstopper with commit. I'm building a
> test program now to see.
Everything was fine with my test code:
String url = "http://host:port/solr/core";
SolrServer server = new CommonsHttpSolrServer(url);
server.commit();
server.commit(true,true);
The reason that I thought it might be a problem is because of bugs in
other Solr APIs, like this one:
https://bugs.php.net/bug.php?id=62332
I'm cautiously optimistic that you'll be able to use a SolrJ 3.5.0 app
against a 4.2.1 server, though you may end up adjusting the server
config. If the config originated with the old server version, it's less
likely that it will need adjusting.
Thanks,
Shawn
RE: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Posted by "Lee, Peter" <Pe...@proquest.com>.
Shawn,
Sorry I did not acknowledge the additional information you provided.
I'd have to go back and re-examine all of the 3.5 settings again as we had to much with them somewhat to get 4.2.1 to work. Q.alt was a bit trickey, I have to review our notes on that.
I solved the problem of the missing "q" parameter exactly as you suggested: by putting q=*:* in the defaults portion of the request handler and we started getting our results again.
-----Original Message-----
From: Lee, Peter
Sent: Tuesday, May 14, 2013 5:19 PM
To: solr-user@lucene.apache.org
Subject: RE: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Sounds like I may not have all of the conditions correctly identified. Or rather, things in our environment that I did not think were a factor may very well be. For one thing, I see I neglected to mention that this was a grouping (field collapsing) query. Let me give you more complete information about the query...it will probably help.
I can tell you that after the request handler processing was complete, these were the only parameters that were set in the query:
q - was not set
defType = edismax
df = <was set>
echoParams = explicit
rows = 100
start = 0
fq = <was set>
group = true
group.field = <was set>
group.limit = 1
group.offset = 0
group.cache.percent = 100
fl = <set to various fields>
shards = <set to the list of shards>
All of the above parameters were set in the "defaults" portion of the request handler definition. Nothing else was being set in any other part of the request handler definition. Also, the raw query coming into the system contained ONLY the request handler specification...nothing else (all other parameters were being added by the request handler).
Perhaps with this more complete information you might be able to recreate the issue. I would try right now but I'm under the gun for a release so I'll pass this information off to you. If you are still unsuccessful when we get this release out I'll see if I can tinker with it more and see what the determining factors are in the behavior we were seeing.
Of course, other settings in the config files might be impacting this behavior...but one thing at a time I suppose.
Thanks.
Peter S. Lee
-----Original Message-----
From: Shawn Heisey [mailto:solr@elyograg.org]
Sent: Tuesday, May 14, 2013 4:54 PM
To: solr-user@lucene.apache.org
Subject: Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1
On 5/14/2013 1:44 PM, Lee, Peter wrote:
> The cause:
> We had an unintentional case that occurred through one request handler such that after the query was processed through the RH and the parameters were set, there were fq variables set but no actual "q" (query) param.
> - Under solr 3.5, solr seems to assume you MEANT to specify q=*:*
> - Under solr 4.2.1, solr makes no such assumption (or so it seems). It appears as if solr has decided that since we didn't bother to include a 'q' parameter, it isn't going to bother to search for anything (yes, I'm anthropomorphizing...it was a late night). I tried the same query with the same request handler back and forth between the two versions of solr server and one returned my data set and the other gave me zero hits.
I can't seem to duplicate this behavior. If I send a request to 3.5.0 with no q parameter and an fq parameter, I get an exception:
http://server35:port/solr/ncmain/select?rows=0&fq=field:value
--
HTTP ERROR 500
Problem accessing /solr/ncmain/select. Reason:
null
java.lang.NullPointerException
--
If I send the same request to a 4.2.1 server, I get a response, but numFound is zero:
http://server421:port/solr/ncmain/select?rows=0&fq=field:value
I *had* thought that if you include q.alt=*:* in your request handler definition it would fall back to that, but that appears to only be the case if you are using the dismax/edismax query parser, not the standard parser. I have a different request handler for edismax which includes q.alt in the definition, and the queries above work fine when using that handler instead of /select.
One thing that would most likely work is to include the q parameter in the defaults section of your request handler. If you don't include it in your query, it would pick up the default, but if you did include it, the default would be ignored.
Thanks,
Shawn
RE: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Posted by "Lee, Peter" <Pe...@proquest.com>.
Sounds like I may not have all of the conditions correctly identified. Or rather, things in our environment that I did not think were a factor may very well be. For one thing, I see I neglected to mention that this was a grouping (field collapsing) query. Let me give you more complete information about the query...it will probably help.
I can tell you that after the request handler processing was complete, these were the only parameters that were set in the query:
q - was not set
defType = edismax
df = <was set>
echoParams = explicit
rows = 100
start = 0
fq = <was set>
group = true
group.field = <was set>
group.limit = 1
group.offset = 0
group.cache.percent = 100
fl = <set to various fields>
shards = <set to the list of shards>
All of the above parameters were set in the "defaults" portion of the request handler definition. Nothing else was being set in any other part of the request handler definition. Also, the raw query coming into the system contained ONLY the request handler specification...nothing else (all other parameters were being added by the request handler).
Perhaps with this more complete information you might be able to recreate the issue. I would try right now but I'm under the gun for a release so I'll pass this information off to you. If you are still unsuccessful when we get this release out I'll see if I can tinker with it more and see what the determining factors are in the behavior we were seeing.
Of course, other settings in the config files might be impacting this behavior...but one thing at a time I suppose.
Thanks.
Peter S. Lee
-----Original Message-----
From: Shawn Heisey [mailto:solr@elyograg.org]
Sent: Tuesday, May 14, 2013 4:54 PM
To: solr-user@lucene.apache.org
Subject: Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1
On 5/14/2013 1:44 PM, Lee, Peter wrote:
> The cause:
> We had an unintentional case that occurred through one request handler such that after the query was processed through the RH and the parameters were set, there were fq variables set but no actual "q" (query) param.
> - Under solr 3.5, solr seems to assume you MEANT to specify q=*:*
> - Under solr 4.2.1, solr makes no such assumption (or so it seems). It appears as if solr has decided that since we didn't bother to include a 'q' parameter, it isn't going to bother to search for anything (yes, I'm anthropomorphizing...it was a late night). I tried the same query with the same request handler back and forth between the two versions of solr server and one returned my data set and the other gave me zero hits.
I can't seem to duplicate this behavior. If I send a request to 3.5.0 with no q parameter and an fq parameter, I get an exception:
http://server35:port/solr/ncmain/select?rows=0&fq=field:value
--
HTTP ERROR 500
Problem accessing /solr/ncmain/select. Reason:
null
java.lang.NullPointerException
--
If I send the same request to a 4.2.1 server, I get a response, but numFound is zero:
http://server421:port/solr/ncmain/select?rows=0&fq=field:value
I *had* thought that if you include q.alt=*:* in your request handler definition it would fall back to that, but that appears to only be the case if you are using the dismax/edismax query parser, not the standard parser. I have a different request handler for edismax which includes q.alt in the definition, and the queries above work fine when using that handler instead of /select.
One thing that would most likely work is to include the q parameter in the defaults section of your request handler. If you don't include it in your query, it would pick up the default, but if you did include it, the default would be ignored.
Thanks,
Shawn
Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Posted by Shawn Heisey <so...@elyograg.org>.
On 5/14/2013 1:44 PM, Lee, Peter wrote:
> The cause:
> We had an unintentional case that occurred through one request handler such that after the query was processed through the RH and the parameters were set, there were fq variables set but no actual "q" (query) param.
> - Under solr 3.5, solr seems to assume you MEANT to specify q=*:*
> - Under solr 4.2.1, solr makes no such assumption (or so it seems). It appears as if solr has decided that since we didn't bother to include a 'q' parameter, it isn't going to bother to search for anything (yes, I'm anthropomorphizing...it was a late night). I tried the same query with the same request handler back and forth between the two versions of solr server and one returned my data set and the other gave me zero hits.
I can't seem to duplicate this behavior. If I send a request to 3.5.0
with no q parameter and an fq parameter, I get an exception:
http://server35:port/solr/ncmain/select?rows=0&fq=field:value
--
HTTP ERROR 500
Problem accessing /solr/ncmain/select. Reason:
null
java.lang.NullPointerException
--
If I send the same request to a 4.2.1 server, I get a response, but
numFound is zero:
http://server421:port/solr/ncmain/select?rows=0&fq=field:value
I *had* thought that if you include q.alt=*:* in your request handler
definition it would fall back to that, but that appears to only be the
case if you are using the dismax/edismax query parser, not the standard
parser. I have a different request handler for edismax which includes
q.alt in the definition, and the queries above work fine when using that
handler instead of /select.
One thing that would most likely work is to include the q parameter in
the defaults section of your request handler. If you don't include it
in your query, it would pick up the default, but if you did include it,
the default would be ignored.
Thanks,
Shawn
RE: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Posted by "Jason M. Hellman" <jh...@innoventsolutions.com>.
Peter,
Thanks for taking the time to spell out what you were going
through. It's great to have details like to to mull over.
Jason
On
2013-05-14 12:44, Lee, Peter wrote:
> Thank you one and all for your
input.
>
> The problem we were tripping over turned out NOT to be
related to using solrj 3.5 client and solr 4.2.1 server. We are, as of
this minute, feeling confident we can put this into production. We are
still doing some testing, but thus far we have hit all of the big
hitters and they have all performed great.
>
> The only problems we
have tripped over have to do with the changes in Solr config files
(understandable) and also changes in how solr behaves in certain
conditions. For example, the problem we just tracked down had to do with
the fact that solr was giving us successful return codes but returning
no matches...no matter what we did.
>
> The cause:
> We had an
unintentional case that occurred through one request handler such that
after the query was processed through the RH and the parameters were
set, there were fq variables set but no actual "q" (query) param.
> -
Under solr 3.5, solr seems to assume you MEANT to specify q=*:*
> -
Under solr 4.2.1, solr makes no such assumption (or so it seems). It
appears as if solr has decided that since we didn't bother to include a
'q' parameter, it isn't going to bother to search for anything (yes, I'm
anthropomorphizing...it was a late night). I tried the same query with
the same request handler back and forth between the two versions of solr
server and one returned my data set and the other gave me zero hits.
>
> This kind of behavior change between 3.5 and 4.2.1 has caused us the
most stumbles. Solrj 3.5 seems to work just fine for our use (which, as
stated before, is very simple). Again I will state that our use of solrj
is only at runtime, and we have only been sending very simple queries
(no indexing occurring through solrj 3.5) that are either exact match or
else simple analyzed text fields.
>
> For these limited searches we are
feeling confident to go to production with this setup. We hope to have
the solrj version upgraded (which requires a java upgrade, which
requires work on the application as we've already determined that it
won't work correctly on Java 7) in the near future and then we won't
have to worry about it any longer.
>
> I hope this information is of
help to you or anyone else reading this thread. I appreciate all of the
comments people have made to assist us in this matter.
>
> Thank you.
>
> Peter S. Lee
>
> -----Original Message-----
> From: Robert J.
Haschart [mailto:rh9ec@virginia.edu]
> Sent: Sunday, May 12, 2013 11:29
PM
> To: solr-user@lucene.apache.org
> Subject: Re: Looking to see if
solrj 3.5 could be used with solr server 4.2.1
>
> Peter,
>
> In the
work I have done for the project SolrMarc, which various sites use to
index Marc records into Solr. It ships as a binary version that includes
a slightly modified version of solrj 3.5, which it uses to communicate
with
> whatever version of solr that site uses. It can operate with
solr 1.4,
> solr 3.x, and at least solr 4.0 and solr 4.1 (and in all
likelihood solr
> 4.2 as well). I will check tomorrow to find what
specific changes were
> needed for it to work with solr 4.x.
>
>
-Bob
>
> On Mon, 13 May 2013 02:11:02 +0000
> "Lee, Peter"
<Pe...@proquest.com> wrote:
>
>> Shawn, Thanks for the feedback. I
did read carefully through your thread before I posted as it looked
close...but as you say..."backwards"...to what we are trying to do.
Fortunately for us, "commit" doesn't enter the picture. Our index at
runtime is effectively "read only," and the indexing and committing are
done by programs that don't need to use the older solrj (3.5) version.
It is our runtime application that we need to see if we can get to run
on solrj 3.5 for a short time longer. I *do* think our 3.5 client is
using javabin, so I will look at your suggested work around. All had
been going well but we just hit a bump in the road and we are
investigating now. Your information may turn out to be invaluable.
Either way it is greatly appreciated. Thanks again for your help. Peter
Lee -----Original Message----- From: Shawn Heisey
[mailto:solr@elyograg.org] Sent: Sunday, May 12, 2013 1:22 AM To:
solr-user@lucene.apache.orgSubject: Re: Looking to see if solrj 3.5
could be used with solr server 4.2.1 On 5/11/2013 9:36 PM, Lee, Peter
wrote:
>>
>>> I've reviewed all of the release notes and we've been
doing testing to see if solrj that came with solr 3.5 would work with
solr server 4.2.1. We are not using any of the new features of
4.2.1...we upgraded purely for the improved performance and much smaller
memory footprint of the indexes. While I have not identified anything in
the release notes that looks like a deal breaker, I also realize that
the powers that be may be thinking that this is such a no brainer
question (why would ANYONE want to use solrj 3.5 with solr 4.2.1) that
it simply was assumed obvious and did not need stating.
>> Initial note:
There might be a showstopper with commit. I'm building a test program
now to see. Assuming that is all clear, then the following will apply:
We've just been having a discussion about this very thing, though in the
other direction - SolrJ 4.2.1 and Solr 3.x. From the research and
experimentation I've done both in the past and for the recent
discussion, as long as you don't try to set the request writer to
Binary, it should work with a fairly vanilla Solr 4.x config. If you
define the /update/javabin handler in your Solr 4.x config, it should
work even if you are using the binary request writer. <requestHandler
name="/update/javabin" class="solr.BinaryUpdateRequestHandler" /> Most
potential problems are likely to be things that you can work out by
adjusting the server config. Thanks, Shawn
RE: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Posted by "Lee, Peter" <Pe...@proquest.com>.
Thank you one and all for your input.
The problem we were tripping over turned out NOT to be related to using solrj 3.5 client and solr 4.2.1 server. We are, as of this minute, feeling confident we can put this into production. We are still doing some testing, but thus far we have hit all of the big hitters and they have all performed great.
The only problems we have tripped over have to do with the changes in Solr config files (understandable) and also changes in how solr behaves in certain conditions. For example, the problem we just tracked down had to do with the fact that solr was giving us successful return codes but returning no matches...no matter what we did.
The cause:
We had an unintentional case that occurred through one request handler such that after the query was processed through the RH and the parameters were set, there were fq variables set but no actual "q" (query) param.
- Under solr 3.5, solr seems to assume you MEANT to specify q=*:*
- Under solr 4.2.1, solr makes no such assumption (or so it seems). It appears as if solr has decided that since we didn't bother to include a 'q' parameter, it isn't going to bother to search for anything (yes, I'm anthropomorphizing...it was a late night). I tried the same query with the same request handler back and forth between the two versions of solr server and one returned my data set and the other gave me zero hits.
This kind of behavior change between 3.5 and 4.2.1 has caused us the most stumbles. Solrj 3.5 seems to work just fine for our use (which, as stated before, is very simple). Again I will state that our use of solrj is only at runtime, and we have only been sending very simple queries (no indexing occurring through solrj 3.5) that are either exact match or else simple analyzed text fields.
For these limited searches we are feeling confident to go to production with this setup. We hope to have the solrj version upgraded (which requires a java upgrade, which requires work on the application as we've already determined that it won't work correctly on Java 7) in the near future and then we won't have to worry about it any longer.
I hope this information is of help to you or anyone else reading this thread. I appreciate all of the comments people have made to assist us in this matter.
Thank you.
Peter S. Lee
-----Original Message-----
From: Robert J. Haschart [mailto:rh9ec@virginia.edu]
Sent: Sunday, May 12, 2013 11:29 PM
To: solr-user@lucene.apache.org
Subject: Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Peter,
In the work I have done for the project SolrMarc, which various sites use to index Marc records into Solr. It ships as a binary version that includes a slightly modified version of solrj 3.5, which it uses to communicate with
whatever version of solr that site uses. It can operate with solr 1.4,
solr 3.x, and at least solr 4.0 and solr 4.1 (and in all likelihood solr
4.2 as well). I will check tomorrow to find what specific changes were
needed for it to work with solr 4.x.
-Bob
On Mon, 13 May 2013 02:11:02 +0000
"Lee, Peter" <Pe...@proquest.com> wrote:
> Shawn,
>
> Thanks for the feedback. I did read carefully through your thread
>before I posted as it looked close...but as you say..."backwards"...to
>what we are trying to do.
>
>Fortunately for us, "commit" doesn't enter the picture. Our index at
>runtime is effectively "read only," and the indexing and committing are
>done by programs that don't need to use the older solrj (3.5) version.
>It is our runtime application that we need to see if we can get to run
>on solrj 3.5 for a short time longer.
>
> I *do* think our 3.5 client is using javabin, so I will look at your
>suggested work around. All had been going well but we just hit a bump
>in the road and we are investigating now. Your information may turn out
>to be invaluable. Either way it is greatly appreciated.
>
> Thanks again for your help.
>
> Peter Lee
>
> -----Original Message-----
>From: Shawn Heisey [mailto:solr@elyograg.org]
> Sent: Sunday, May 12, 2013 1:22 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Looking to see if solrj 3.5 could be used with solr
>server
>4.2.1
>
> On 5/11/2013 9:36 PM, Lee, Peter wrote:
>> I've reviewed all of the release notes and we've been doing testing
>>to see if solrj that came with solr 3.5 would work with solr server
>>4.2.1. We are not using any of the new features of 4.2.1...we upgraded
>>purely for the improved performance and much smaller memory footprint of the indexes.
>>While I have not identified anything in the release notes that looks
>>like a deal breaker, I also realize that the powers that be may be
>>thinking that this is such a no brainer question (why would ANYONE
>>want to use solrj 3.5 with solr 4.2.1) that it simply was assumed
>>obvious and did not need stating.
>
> Initial note: There might be a showstopper with commit. I'm building
>a test program now to see. Assuming that is all clear, then the
>following will apply:
>
> We've just been having a discussion about this very thing, though in
>the other direction - SolrJ 4.2.1 and Solr 3.x. From the research and
>experimentation I've done both in the past and for the recent
>discussion, as long as you don't try to set the request writer to
>Binary, it should work with a fairly vanilla Solr 4.x config.
>
> If you define the /update/javabin handler in your Solr 4.x config, it
>should work even if you are using the binary request writer.
>
> <requestHandler name="/update/javabin"
> class="solr.BinaryUpdateRequestHandler" />
>
> Most potential problems are likely to be things that you can work out
>by adjusting the server config.
>
> Thanks,
> Shawn
>
>
>
>
Re: Looking to see if solrj 3.5 could be used with solr server
4.2.1
Posted by "Robert J. Haschart" <rh...@virginia.edu>.
Peter,
In the work I have done for the project SolrMarc, which various sites use to
index Marc records into Solr. It ships as a binary version that includes a
slightly modified version of solrj 3.5, which it uses to communicate with
whatever version of solr that site uses. It can operate with solr 1.4,
solr 3.x, and at least solr 4.0 and solr 4.1 (and in all likelihood solr
4.2 as well). I will check tomorrow to find what specific changes were
needed for it to work with solr 4.x.
-Bob
On Mon, 13 May 2013 02:11:02 +0000
"Lee, Peter" <Pe...@proquest.com> wrote:
> Shawn,
>
> Thanks for the feedback. I did read carefully through your thread before I
>posted as it looked close...but as you say..."backwards"...to what we are
>trying to do.
>
>Fortunately for us, "commit" doesn't enter the picture. Our index at
>runtime is effectively "read only," and the indexing and committing are
>done by programs that don't need to use the older solrj (3.5) version. It
>is our runtime application that we need to see if we can get to run on
>solrj 3.5 for a short time longer.
>
> I *do* think our 3.5 client is using javabin, so I will look at your
>suggested work around. All had been going well but we just hit a bump in
>the road and we are investigating now. Your information may turn out to be
>invaluable. Either way it is greatly appreciated.
>
> Thanks again for your help.
>
> Peter Lee
>
> -----Original Message-----
>From: Shawn Heisey [mailto:solr@elyograg.org]
> Sent: Sunday, May 12, 2013 1:22 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Looking to see if solrj 3.5 could be used with solr server
>4.2.1
>
> On 5/11/2013 9:36 PM, Lee, Peter wrote:
>> I've reviewed all of the release notes and we've been doing testing to see
>>if solrj that came with solr 3.5 would work with solr server 4.2.1. We are
>>not using any of the new features of 4.2.1...we upgraded purely for the
>>improved performance and much smaller memory footprint of the indexes.
>>While I have not identified anything in the release notes that looks like a
>>deal breaker, I also realize that the powers that be may be thinking that
>>this is such a no brainer question (why would ANYONE want to use solrj 3.5
>>with solr 4.2.1) that it simply was assumed obvious and did not need
>>stating.
>
> Initial note: There might be a showstopper with commit. I'm building a
>test program now to see. Assuming that is all clear, then the following
>will apply:
>
> We've just been having a discussion about this very thing, though in the
>other direction - SolrJ 4.2.1 and Solr 3.x. From the research and
>experimentation I've done both in the past and for the recent discussion,
>as long as you don't try to set the request writer to Binary, it should
>work with a fairly vanilla Solr 4.x config.
>
> If you define the /update/javabin handler in your Solr 4.x config, it
>should work even if you are using the binary request writer.
>
> <requestHandler name="/update/javabin"
> class="solr.BinaryUpdateRequestHandler" />
>
> Most potential problems are likely to be things that you can work out by
>adjusting the server config.
>
> Thanks,
> Shawn
>
>
>
>
RE: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Posted by "Lee, Peter" <Pe...@proquest.com>.
Shawn,
Thanks for the feedback. I did read carefully through your thread before I posted as it looked close...but as you say..."backwards"...to what we are trying to do.
Fortunately for us, "commit" doesn't enter the picture. Our index at runtime is effectively "read only," and the indexing and committing are done by programs that don't need to use the older solrj (3.5) version. It is our runtime application that we need to see if we can get to run on solrj 3.5 for a short time longer.
I *do* think our 3.5 client is using javabin, so I will look at your suggested work around. All had been going well but we just hit a bump in the road and we are investigating now. Your information may turn out to be invaluable. Either way it is greatly appreciated.
Thanks again for your help.
Peter Lee
-----Original Message-----
From: Shawn Heisey [mailto:solr@elyograg.org]
Sent: Sunday, May 12, 2013 1:22 AM
To: solr-user@lucene.apache.org
Subject: Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1
On 5/11/2013 9:36 PM, Lee, Peter wrote:
> I've reviewed all of the release notes and we've been doing testing to see if solrj that came with solr 3.5 would work with solr server 4.2.1. We are not using any of the new features of 4.2.1...we upgraded purely for the improved performance and much smaller memory footprint of the indexes. While I have not identified anything in the release notes that looks like a deal breaker, I also realize that the powers that be may be thinking that this is such a no brainer question (why would ANYONE want to use solrj 3.5 with solr 4.2.1) that it simply was assumed obvious and did not need stating.
Initial note: There might be a showstopper with commit. I'm building a test program now to see. Assuming that is all clear, then the following will apply:
We've just been having a discussion about this very thing, though in the other direction - SolrJ 4.2.1 and Solr 3.x. From the research and experimentation I've done both in the past and for the recent discussion, as long as you don't try to set the request writer to Binary, it should work with a fairly vanilla Solr 4.x config.
If you define the /update/javabin handler in your Solr 4.x config, it should work even if you are using the binary request writer.
<requestHandler name="/update/javabin"
class="solr.BinaryUpdateRequestHandler" />
Most potential problems are likely to be things that you can work out by adjusting the server config.
Thanks,
Shawn
Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Posted by Shawn Heisey <so...@elyograg.org>.
On 5/11/2013 9:36 PM, Lee, Peter wrote:
> I've reviewed all of the release notes and we've been doing testing to see if solrj that came with solr 3.5 would work with solr server 4.2.1. We are not using any of the new features of 4.2.1...we upgraded purely for the improved performance and much smaller memory footprint of the indexes. While I have not identified anything in the release notes that looks like a deal breaker, I also realize that the powers that be may be thinking that this is such a no brainer question (why would ANYONE want to use solrj 3.5 with solr 4.2.1) that it simply was assumed obvious and did not need stating.
Initial note: There might be a showstopper with commit. I'm building a
test program now to see. Assuming that is all clear, then the following
will apply:
We've just been having a discussion about this very thing, though in the
other direction - SolrJ 4.2.1 and Solr 3.x. From the research and
experimentation I've done both in the past and for the recent
discussion, as long as you don't try to set the request writer to
Binary, it should work with a fairly vanilla Solr 4.x config.
If you define the /update/javabin handler in your Solr 4.x config, it
should work even if you are using the binary request writer.
<requestHandler name="/update/javabin"
class="solr.BinaryUpdateRequestHandler" />
Most potential problems are likely to be things that you can work out by
adjusting the server config.
Thanks,
Shawn
RE: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Posted by "Lee, Peter" <Pe...@proquest.com>.
Michael,
Thanks for the information. We are tracking down an issue now that might be related...but we are far from having determined that yet. Either way I'll let you know how it turns out.
-----Original Message-----
From: Michael Sokolov [mailto:msokolov@safaribooksonline.com]
Sent: Sunday, May 12, 2013 10:34 AM
To: solr-user@lucene.apache.org
Cc: Lee, Peter
Subject: Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1
On 5/11/2013 11:36 PM, Lee, Peter wrote:
> If you have any information regarding whether or not this might work (as in "yeah, we did that and it worked okay"...or..."no, that won't work because protocol XYZ changed between versions and <yada,yada,yada>") I would appreciate it. As stated above, simple cases using both exact match and analyzed fields have been shown to work. We are already investigating the more involved cases, but I figured it wouldn't hurt to ask for the input of the solr community.
>
> With much appreciation,
>
> Peter S. Lee
Peter - I ran some simple tests of 3.4 client and 4.2 server and didn't hit any problems. However, this isn't in production yet, and I haven't had a chance to test extensively. I would certainly be interested to hear if you run into any problems. Our plan is to upgrade the clients first, so I was more interested in testing 4.2 client/3.4 server. There was one issue there, but I think there is a pretty straightforward workaround (see the recent discussion w/Shawn).
-Mike
Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Posted by Michael Sokolov <ms...@safaribooksonline.com>.
On 5/11/2013 11:36 PM, Lee, Peter wrote:
> If you have any information regarding whether or not this might work (as in "yeah, we did that and it worked okay"...or..."no, that won't work because protocol XYZ changed between versions and <yada,yada,yada>") I would appreciate it. As stated above, simple cases using both exact match and analyzed fields have been shown to work. We are already investigating the more involved cases, but I figured it wouldn't hurt to ask for the input of the solr community.
>
> With much appreciation,
>
> Peter S. Lee
Peter - I ran some simple tests of 3.4 client and 4.2 server and didn't
hit any problems. However, this isn't in production yet, and I haven't
had a chance to test extensively. I would certainly be interested to
hear if you run into any problems. Our plan is to upgrade the clients
first, so I was more interested in testing 4.2 client/3.4 server. There
was one issue there, but I think there is a pretty straightforward
workaround (see the recent discussion w/Shawn).
-Mike