Shawn,
I don't believe its the container because we use the same container
in another setup that has 6 cores which is serving almost 1.8 Million
requests a day without a hitch.
If you look at my email the container that is running SOLR got the request
params (http access logs provided in first email) but when it goes through
the SOLR app/code on the container (probably through request filters or
dispatchers..I don't know exactly) its getting lost, which is what I am
trying to understand. I want to understand under what situations this mat
happen.
Having said that this application that uses this problematic SOLR instance
retrieves large number of facets results for each of 26 facets for each
query and every query is a group query, would that cause any issues with
SOLR caches that could lead to the issues like I am facing ???
With regards to the port number, our paranoid security folks wanted me to
not reveal our ports so I put it as 80 without thinking :-), I assure use
that its not 80.
Thanks,
Ravi
On Wed, May 1, 2013 at 6:03 PM, Shawn Heisey <s...@elyograg.org> wrote:
> On 5/1/2013 3:14 PM, Ravi Solr wrote:
>
>> We are using Solr 3.6.2 with a single core setup on a glassfish server,
>> every 4-5 hours the server gradually gets into a some kind of a
>> inconsistent state and stops accepting any queries giving back cached
>> results. Even the core reload fails giving the following. Has anybody
>> experienced such behavior ? Can anybody help me understand why this might
>> happen ?
>>
>> http://searchserver:80/solr/**admin/cores?action=RELOAD&**core=core1<http://searchserver:80/solr/admin/cores?action=RELOAD&core=core1>
>>
>> <response>
>> <lst name="responseHeader">
>> <int name="status">0</int>
>> <int name="QTime">9</int>
>> </lst>
>> <lst name="status">
>>
>
> It is dropping the parameters from the /admin/cores request too, so it
> returns status instead of acting on the RELOAD.
>
> This is acting like a servlet container issue more than a Solr issue. It's
> always possible that it actually is Solr.
>
> It's a little unusual to see Solr running on port 80. It's not
> impossible, just not the normal setup, because exposing Solr directly to
> the outside world is a very bad idea, so it's a lot safer to have it listen
> on another port.
>
> Is glassfish actually listening on port 80? If it's not, then you
> probably have something acting as a proxy in front of Solr. If your
> platform is a UNIX variant or Linux and has a fully functional 'lsof'
> command, the following will tell you which process is bound to port 80:
>
> lsof -nPi | grep ":80"
>
> Can you try running Solr under the jetty that's included with the Solr
> download? For Solr 3.6.2, this is a slightly modified Jetty 6. You can't
> use the Jetty 8 that's included with a newer version of Solr. If port 80
> is a requirement, that should be possible as long as it's running as root.
>
> Thanks,
> Shawn
>
>
