simple date query

2013-07-10 Thread Marcos Mendez
Hi,

I'm trying to do something like startDate_tdt = NOW = endDate_tdt. Any ideas 
how I can implement this in a query? I don't think the normal range query will 
work.

Regards,
Marcos

atomic updates w/ double field

2013-05-08 Thread Marcos Mendez

Hi,

I'm using solr 4.0 and I'm using an atomic update to increment a tdouble 3 
times with the same value (99.4). The third time it is incremented the values 
comes out to 298.25. Has anyone seen this error or how to fix it? 
Maybe I should use the regular double instead of a tdouble?

1 x weight_td:{set:0.0}

 3 x weight_td:{inc:99.4}

Schema information:

dynamicField name=*_d  type=double  indexed=true  stored=true/
dynamicField name=*_tdtype=tdouble  indexed=true  stored=true/
fieldType name=double class=solr.TrieDoubleField precisionStep=0 
positionIncrementGap=0/
fieldType name=tdouble class=solr.TrieDoubleField precisionStep=8 
positionIncrementGap=0/




Re: memory leak - multiple cores

2013-02-12 Thread Marcos Mendez
Many thanks! I will try to use the CoreAdminHandler and see if that solves the 
issue!

On Feb 12, 2013, at 9:05 AM, Michael Della Bitta wrote:

 I should also say that there can easily be memory leaked from permgen
 space when reloading webapps in Tomcat regardless of what resources
 the app creates because class references from the context classloader
 to the parent classloader can't be collected appropriately, so
 restarting Tomcat periodically when you reload webapps is a good
 practice either way.
 
 Michael Della Bitta
 
 
 Appinions
 18 East 41st Street, 2nd Floor
 New York, NY 10017-6271
 
 www.appinions.com
 
 Where Influence Isn’t a Game
 
 
 On Tue, Feb 12, 2013 at 9:03 AM, Michael Della Bitta
 michael.della.bi...@appinions.com wrote:
 Marcos,
 
 You could consider using the CoreAdminHandler instead:
 
 http://wiki.apache.org/solr/CoreAdmin#CoreAdminHandler
 
 It works extremely well.
 
 Otherwise, you should periodically restart Tomcat. I'm not sure how
 much memory would be leaked, but it's likely not going to have much of
 an impact for a few iterations.
 
 
 Michael Della Bitta
 
 
 Appinions
 18 East 41st Street, 2nd Floor
 New York, NY 10017-6271
 
 www.appinions.com
 
 Where Influence Isn’t a Game
 
 
 On Mon, Feb 11, 2013 at 8:45 PM, Marcos Mendez mar...@jitisoft.com wrote:
 Hi Michael,
 
 Yes, we do intend to reload Solr when deploying new cores. So we deploy it, 
 update solr.xml and then restart Solr only. So this will happen sometimes 
 in production, but mostly testing. Which means it will be a real pain. Any 
 way to fix this?
 
 Also, I'm running geronimo with -Xmx1024m -XX:MaxPermSize=256m.
 
 Regards,
 Marcos
 
 On Feb 6, 2013, at 10:54 AM, Michael Della Bitta wrote:
 
 Marcos,
 
 The later 3 errors are common and won't pose a problem unless you
 intend to reload the Solr application without restarting Geronimo
 often.
 
 The first error, however, shouldn't happen. Have you changed the size
 of PermGen at all? I noticed this error while testing Solr 4.0 in
 Tomcat, but haven't seen it with Solr 4.1 (yet), so if you're on 4.0,
 you might want to try upgrading.
 
 
 Michael Della Bitta
 
 
 Appinions
 18 East 41st Street, 2nd Floor
 New York, NY 10017-6271
 
 www.appinions.com
 
 Where Influence Isn’t a Game
 
 
 On Wed, Feb 6, 2013 at 6:09 AM, Marcos Mendez mar...@jitisoft.com wrote:
 Hi,
 
 I'm deploying the SOLR war in Geronimo, with multiple cores. I'm seeing 
 the
 following issue and it eats up a lot of memory when shutting down. Has
 anyone seen this and have an idea how to solve it?
 
 Exception in thread DefaultThreadPool 196 java.lang.OutOfMemoryError:
 PermGen space
 2013-02-05 20:13:34,747 ERROR [ConcurrentLRUCache] ConcurrentLRUCache was
 not destroyed prior to finalize(), indicates a bug -- POSSIBLE RESOURCE
 LEAK!!!
 2013-02-05 20:13:34,747 ERROR [ConcurrentLRUCache] ConcurrentLRUCache was
 not destroyed prior to finalize(), indicates a bug -- POSSIBLE RESOURCE
 LEAK!!!
 2013-02-05 20:13:34,747 ERROR [CoreContainer] CoreContainer was not
 shutdown prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!!
 instance=2080324477
 
 Regards,
 Marcos
 



Re: memory leak - multiple cores

2013-02-11 Thread Marcos Mendez
Hi Michael,

Yes, we do intend to reload Solr when deploying new cores. So we deploy it, 
update solr.xml and then restart Solr only. So this will happen sometimes in 
production, but mostly testing. Which means it will be a real pain. Any way to 
fix this?

Also, I'm running geronimo with -Xmx1024m -XX:MaxPermSize=256m. 

Regards,
Marcos

On Feb 6, 2013, at 10:54 AM, Michael Della Bitta wrote:

 Marcos,
 
 The later 3 errors are common and won't pose a problem unless you
 intend to reload the Solr application without restarting Geronimo
 often.
 
 The first error, however, shouldn't happen. Have you changed the size
 of PermGen at all? I noticed this error while testing Solr 4.0 in
 Tomcat, but haven't seen it with Solr 4.1 (yet), so if you're on 4.0,
 you might want to try upgrading.
 
 
 Michael Della Bitta
 
 
 Appinions
 18 East 41st Street, 2nd Floor
 New York, NY 10017-6271
 
 www.appinions.com
 
 Where Influence Isn’t a Game
 
 
 On Wed, Feb 6, 2013 at 6:09 AM, Marcos Mendez mar...@jitisoft.com wrote:
 Hi,
 
 I'm deploying the SOLR war in Geronimo, with multiple cores. I'm seeing the
 following issue and it eats up a lot of memory when shutting down. Has
 anyone seen this and have an idea how to solve it?
 
 Exception in thread DefaultThreadPool 196 java.lang.OutOfMemoryError:
 PermGen space
 2013-02-05 20:13:34,747 ERROR [ConcurrentLRUCache] ConcurrentLRUCache was
 not destroyed prior to finalize(), indicates a bug -- POSSIBLE RESOURCE
 LEAK!!!
 2013-02-05 20:13:34,747 ERROR [ConcurrentLRUCache] ConcurrentLRUCache was
 not destroyed prior to finalize(), indicates a bug -- POSSIBLE RESOURCE
 LEAK!!!
 2013-02-05 20:13:34,747 ERROR [CoreContainer] CoreContainer was not
 shutdown prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!!
 instance=2080324477
 
 Regards,
 Marcos



memory leak - multiple cores

2013-02-06 Thread Marcos Mendez
Hi,

I'm deploying the SOLR war in Geronimo, with multiple cores. I'm seeing the
following issue and it eats up a lot of memory when shutting down. Has
anyone seen this and have an idea how to solve it?

Exception in thread DefaultThreadPool 196 java.lang.OutOfMemoryError:
PermGen space
2013-02-05 20:13:34,747 ERROR [ConcurrentLRUCache] ConcurrentLRUCache was
not destroyed prior to finalize(), indicates a bug -- POSSIBLE RESOURCE
LEAK!!!
2013-02-05 20:13:34,747 ERROR [ConcurrentLRUCache] ConcurrentLRUCache was
not destroyed prior to finalize(), indicates a bug -- POSSIBLE RESOURCE
LEAK!!!
2013-02-05 20:13:34,747 ERROR [CoreContainer] CoreContainer was not
shutdown prior to finalize(), indicates a bug -- POSSIBLE RESOURCE LEAK!!!
 instance=2080324477

Regards,
Marcos


Re: solr atomic update

2013-02-05 Thread Marcos Mendez
Any ideas on this?


Begin forwarded message:

 From: Marcos Mendez mar...@jitisoft.com
 Subject: solr atomic update
 Date: January 31, 2013 7:09:23 AM EST
 To: solr-user@lucene.apache.org
 
 Is there a way to do an atomic update (inc by 1) and retrieve the value in 
 one operation?



solr atomic update

2013-01-31 Thread Marcos Mendez
Is there a way to do an atomic update (inc by 1) and retrieve the updated value 
in one operation?

SOLR/Velocity Test Cases

2013-01-09 Thread Marcos Mendez
Hi,

I'm trying to write some tests based on SolrTestCaseJ4 that test using velocity 
in SOLR. I found VelocityResponseWriterTest.java, but this does not test that. 
In fact it has a todo to do what I want to do. 

Anyone have an example out there?

I just need to check if velocity is loaded with my configuration. Any help is 
appreciated.

solr war - osgi

2012-12-03 Thread Marcos Mendez
Hi,

Has anyone had any experience repackaging the solr war for osgi? And while I'm 
at it, has anyone done this in geronimo 3.0?

Regards,
Marcos