You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Timothy Stone <ci...@petmystone.com> on 2004/05/18 17:42:44 UTC
Bad file descriptor (IOException) using SearchBean contribution
Lucene Users,
I'm using the SearchBean contribution from the sandbox to implement a
Struts application search with Lucene (taking ACO's advice and going MVC
on the demo app.)
Right now I'm having a problem with using any Document objects that
might be available and getting an IOException.
So basically what I'm doing, and pardon the marshalling code, etc.
I have an action that determines the users desired search (internal via
Lucene or external via Google) and forwards appropiately. If the search
is directed to Lucene I create new SearchBean using:
searchBean = new SearchBean(
FSDirectory.getDirectory(
getServlet().getInitParameter( "index" ),
false ),
query );
This bean is put on the request for use in the results.jsp page.
I'm able to quite a bit of work with the bean, determine hits, page
counts, etc. except yank a document and display the indexed fields (I'm
using the org.apache.lucene.demo.IndexHTML) such as "title", "summary",
and "url".
curr position: <%= searchBean.getHitsIterator().getCurrentPosition() %>
<% if( searchBean.getHitsIterator().hasNext() ) {
Document doc = searchBean.getHitsIterator().next(); // BOOM!
}
%>
Any ideas? I only see K. Burton's FSDirectory patch in the archives, but
nothing I don't have from CVS.
Here's the stack trace:
java.io.IOException: Bad file descriptor
at java.io.RandomAccessFile.seek(Native Method)
at org.apache.lucene.store.FSInputStream.readInternal(FSDirectory.java:428)
at org.apache.lucene.store.InputStream.refill(InputStream.java:196)
at org.apache.lucene.store.InputStream.readByte(InputStream.java:81)
at org.apache.lucene.store.InputStream.readInt(InputStream.java:111)
at org.apache.lucene.store.InputStream.readLong(InputStream.java:134)
at org.apache.lucene.index.FieldsReader.doc(FieldsReader.java:96)
at org.apache.lucene.index.SegmentReader.document(SegmentReader.java:275)
at org.apache.lucene.search.IndexSearcher.doc(IndexSearcher.java:107)
at org.apache.lucene.search.Hits.doc(Hits.java:130)
at org.apache.lucene.beans.HitsIterator.getDoc(HitsIterator.java:161)
at org.apache.lucene.beans.HitsIterator.next(HitsIterator.java:139)
at org.apache.jsp.results_jsp._jspService(results_jsp.java:117)
...
Many thanks,
Tim
--
/**
* Timothy Stone . www.petmystone.com
* Harrisburg PA . javafueled at petmystone.com
* USA . coffee fueled macintosh zealot
*
* "This Satan's drink [coffee] is so
* delicious, we shall cheat Satan and
* baptize it."
* --Pope Clement VIII
*/
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Lucene and MVC (was Re: Bad file descriptor (IOException) using SearchBean contribution)
Posted by petite_abeille <pe...@mac.com>.
On May 20, 2004, at 04:38, Erik Hatcher wrote:
> OffTopic: havoc and Struts go well together ;) Pick up Tapestry
> instead!
Nah. Keep it really Simple [1] instead :o)
http://simpleweb.sourceforge.net/
PA.
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Lucene and MVC (was Re: Bad file descriptor (IOException) using SearchBean contribution)
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On May 19, 2004, at 8:04 AM, Timothy Stone wrote:
>> Could you elaborate on what you mean by MVC here? A value list
>> handler piece has been developed and links posted to it on this list
>> - if this is the type of thing you're referring to.
>
> Again, maybe I was naively associating the "SearchBean" with something
> that it was not suppose to be doing. To elaborate, I would like to
> take the demo, which has been working with some success for two years
> on my site, and follow the suggestions of Andrew C. Oliver and go
> "Model 2 on the demo."
I've never seen a user story (or use case) that said "this feature must
use MVC" :) What is the purpose of going MVC here? Is it just for
architectural purity?
> So the SearchBean's purpose, as I understood it, was to provide a
> Model 2 component for use in JSPs.
Consider a query that generates a million hits. How should the JSP
iterate over them? In a pure MVC world, the JSP would be pushed the
hits and allowed to display them however it likes. With Lucene Hits,
you get this capability already. I'm just not convinced a wrapper is
needed, especially now that sorting is built-in.
Again, I'm open to being convinced otherwise.
>> A value list handler piece has been developed and links posted to it
>> on this list - if this is the type of thing you're referring to.
>
> I tried looking for references to such, but no luck.
http://www.nitwit.de/vlh2/
Also, for JSP use, there is the taglib contribution in the sandbox that
might be of interest to you. I've not gotten it to work, yet, and it's
not quite my cup of tea (being an anti-JSP kinda guy that is).
> I must admit that I get the feeling that "newbies" to Lucene seem to
> get less attention on the list. I'm one that tries real hard to
> research my question first in the archives (marc.theaimsgroup.com)
> then on the web. Even I get frustrated on some lists where the most
> obvious question is being asked and the asker misses hints and
> outright help.
When I was first learning Ant, I lurked on the ant-user list and when a
question came up that I knew I'd answer it. When one came up that I
didn't know, I'd research it by experimenting and cross-referencing in
the source code to try to figure it out. We really get out of this
community what we put into it, in my opinion. Newbies need to be savvy
and do some homework and not expect everything to be spelled out
beautifully - none of us have time to flesh out full-fledged example
applications to answer every question. Sometimes a question comes
along that I could reply to, but I let it go because I'm crushed for
time as it is. Sometimes I'll answer - especially if the question
piques my curiosity or has some aspect of a challenge for me to learn
something new.
I personally try to answer professionally and thoroughly, but sometimes
I might answer off-the-cuff or quickly and it comes out a bit tersely
or perhaps intimidating. My contributions as a whole, though, are
hopefully taken positively by the community.
> The Lucene User list can be intimidating even for the advanced novice
> who may be on the right track but not phrasing or wording or
> describing the problem or task in front of him/her.
You are not the only one that gets blown away by things on this list.
There are many times I've been baffled and completely mind-blown by
things here - what underlies Lucene and what folks can build around it
is simply astonishing. This is no typical open source project we're
dealing with here. Thankfully the API is so straightforward to use,
though, that Lucene usage is clear - its the bigger picture that is
daunting (to me).
I'm personally reading Managing Gigabytes at the moment, and my head is
spinning. But it is helping me get a clearer picture of the underlying
concepts that Lucene is built upon.
> a new desire to tackle Struts, and well, havoc ensues.
OffTopic: havoc and Struts go well together ;) Pick up Tapestry
instead!
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Bad file descriptor (IOException) using SearchBean contribution
Posted by Timothy Stone <ci...@petmystone.com>.
Erik Hatcher wrote:
> On May 18, 2004, at 1:43 PM, Timothy Stone wrote:
>
>> Erik Hatcher wrote:
>>
>>> Lucene 1.4 (now in release candidate stage) includes built-in sorting
>>> capabilities, so I definitely recommend you have a look at that.
>>> SearchBean is effectively deprecated based on this new much more
>>> powerful feature.
>>> Erik
>>
>>
>> Forgive my naivety, but isn't the purpose of the SearchBean more than
>> just sorting? Without the SearchBean, creating a MVC demo becomes a
>> larger exercise to undertake.
>
>
> Could you elaborate on what you mean by MVC here? A value list handler
> piece has been developed and links posted to it on this list - if this
> is the type of thing you're referring to.
Again, maybe I was naively associating the "SearchBean" with something
that it was not suppose to be doing. To elaborate, I would like to take
the demo, which has been working with some success for two years on my
site, and follow the suggestions of Andrew C. Oliver and go "Model 2 on
the demo."
You and I have moved away in this thread from my original question, why
I am getting the IOException: Bad File Descriptor, *and that is okay*,
I'm learning a lot. However, I hope that we can come back to it later,
if necessary off-list.
So the SearchBean's purpose, as I understood it, was to provide a Model
2 component for use in JSPs.
> A value list handler piece has been developed and links posted to it
> on this list - if this is the type of thing you're referring to.
I tried looking for references to such, but no luck.
[snip]
> I'd love to hear how folks are using SearchBean though, and why they
> feel it is beneficial.
See above as to how I think it could to be used. :)
I agree that Lucene offers a tremendous amount of power! Kudos to all of
the developers working so hard on this. It is a testament to the
flexibility of Java.
I must admit that I get the feeling that "newbies" to Lucene seem to get
less attention on the list. I'm one that tries real hard to research my
question first in the archives (marc.theaimsgroup.com) then on the web.
Even I get frustrated on some lists where the most obvious question is
being asked and the asker misses hints and outright help. The Lucene
User list can be intimidating even for the advanced novice who may be on
the right track but not phrasing or wording or describing the problem or
task in front of him/her. So forgive me, Lucene is a very powerful
API/library (see I understand what Lucene is ;) ) and I get lost in the
new search terminology confronting me. Couple this with a new desire to
tackle Struts, and well, havoc ensues.
Many thanks for your help and answers.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Bad file descriptor (IOException) using SearchBean contribution
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On May 18, 2004, at 1:43 PM, Timothy Stone wrote:
> Erik Hatcher wrote:
>> Lucene 1.4 (now in release candidate stage) includes built-in sorting
>> capabilities, so I definitely recommend you have a look at that.
>> SearchBean is effectively deprecated based on this new much more
>> powerful feature.
>> Erik
>
> Forgive my naivety, but isn't the purpose of the SearchBean more than
> just sorting? Without the SearchBean, creating a MVC demo becomes a
> larger exercise to undertake.
Could you elaborate on what you mean by MVC here? A value list handler
piece has been developed and links posted to it on this list - if this
is the type of thing you're referring to.
Personally I'm skeptical of using such wrappers. Lucene itself
provides the needed wrapping for efficiency to allow you to page
through search results with the least possible resource use. Trying to
pull all results into a collection and iterate them will not scale
unless you leverage some lazy handling like Lucene already provides. I
don't see the need to add an additional intermediate layer. Purists
will claim it "abstracts" the implementation. But, I'm _agile_ and
being so means I have faith in my skills to shift my codebase to a
different search implementation when/if needed, and I definitely do not
foresee that as even being a possibility since Lucene is superb.
I'd love to hear how folks are using SearchBean though, and why they
feel it is beneficial.
> Can anyone elaborate further on what Lucene 1.4 RC 3 offers that
> deprecates SearchBean?
Maybe "deprecates" was too strong - but sorting is completely covered
with built-in capabilities now, and you can see above regarding my MVC
opinions.
It offers sorting by relevance, document id, and any field you've
indexed appropriately (see javadocs for details) as well as custom
sorting implementations. I have, as a prototype, leveraged the custom
sorting implementation to efficiently sort documents (businesses with a
"location" field) by geographic distance from the user doing the query.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Bad file descriptor (IOException) using SearchBean contribution
Posted by Timothy Stone <ci...@petmystone.com>.
Erik Hatcher wrote:
> Lucene 1.4 (now in release candidate stage) includes built-in sorting
> capabilities, so I definitely recommend you have a look at that.
> SearchBean is effectively deprecated based on this new much more
> powerful feature.
>
> Erik
Forgive my naivety, but isn't the purpose of the SearchBean more than
just sorting? Without the SearchBean, creating a MVC demo becomes a
larger exercise to undertake.
Can anyone elaborate further on what Lucene 1.4 RC 3 offers that
deprecates SearchBean?
Many thanks,
Tim
>
> On May 18, 2004, at 11:42 AM, Timothy Stone wrote:
>
>> Lucene Users,
>>
>> I'm using the SearchBean contribution from the sandbox to implement a
>> Struts application search with Lucene (taking ACO's advice and going
>> MVC on the demo app.)
>>
>> Right now I'm having a problem with using any Document objects that
>> might be available and getting an IOException.
>>
>> So basically what I'm doing, and pardon the marshalling code, etc.
>>
>> I have an action that determines the users desired search (internal
>> via Lucene or external via Google) and forwards appropiately. If the
>> search is directed to Lucene I create new SearchBean using:
>>
>> searchBean = new SearchBean(
>> FSDirectory.getDirectory(
>> getServlet().getInitParameter( "index" ),
>> false ),
>> query );
>>
>> This bean is put on the request for use in the results.jsp page.
>>
>> I'm able to quite a bit of work with the bean, determine hits, page
>> counts, etc. except yank a document and display the indexed fields
>> (I'm using the org.apache.lucene.demo.IndexHTML) such as "title",
>> "summary", and "url".
>>
>> curr position: <%= searchBean.getHitsIterator().getCurrentPosition() %>
>>
>> <% if( searchBean.getHitsIterator().hasNext() ) {
>> Document doc = searchBean.getHitsIterator().next(); // BOOM!
>> }
>> %>
>>
>> Any ideas? I only see K. Burton's FSDirectory patch in the archives,
>> but nothing I don't have from CVS.
>>
>> Here's the stack trace:
>>
>> java.io.IOException: Bad file descriptor
>> at java.io.RandomAccessFile.seek(Native Method)
>> at
>> org.apache.lucene.store.FSInputStream.readInternal(FSDirectory.java: 428)
>> at org.apache.lucene.store.InputStream.refill(InputStream.java:196)
>> at org.apache.lucene.store.InputStream.readByte(InputStream.java:81)
>> at org.apache.lucene.store.InputStream.readInt(InputStream.java:111)
>> at org.apache.lucene.store.InputStream.readLong(InputStream.java:134)
>> at org.apache.lucene.index.FieldsReader.doc(FieldsReader.java:96)
>> at
>> org.apache.lucene.index.SegmentReader.document(SegmentReader.java:275)
>> at org.apache.lucene.search.IndexSearcher.doc(IndexSearcher.java:107)
>> at org.apache.lucene.search.Hits.doc(Hits.java:130)
>> at org.apache.lucene.beans.HitsIterator.getDoc(HitsIterator.java:161)
>> at org.apache.lucene.beans.HitsIterator.next(HitsIterator.java:139)
>> at org.apache.jsp.results_jsp._jspService(results_jsp.java:117)
>>
>> ...
>>
>> Many thanks,
>> Tim
>>
--
/**
* Timothy Stone . www.petmystone.com
* Harrisburg PA . javafueled at petmystone.com
* USA . coffee fueled macintosh zealot
*
* "This Satan's drink [coffee] is so
* delicious, we shall cheat Satan and
* baptize it."
* --Pope Clement VIII
*/
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Bad file descriptor (IOException) using SearchBean contribution
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Lucene 1.4 (now in release candidate stage) includes built-in sorting
capabilities, so I definitely recommend you have a look at that.
SearchBean is effectively deprecated based on this new much more
powerful feature.
Erik
On May 18, 2004, at 11:42 AM, Timothy Stone wrote:
> Lucene Users,
>
> I'm using the SearchBean contribution from the sandbox to implement a
> Struts application search with Lucene (taking ACO's advice and going
> MVC on the demo app.)
>
> Right now I'm having a problem with using any Document objects that
> might be available and getting an IOException.
>
> So basically what I'm doing, and pardon the marshalling code, etc.
>
> I have an action that determines the users desired search (internal
> via Lucene or external via Google) and forwards appropiately. If the
> search is directed to Lucene I create new SearchBean using:
>
> searchBean = new SearchBean(
> FSDirectory.getDirectory(
> getServlet().getInitParameter( "index" ),
> false ),
> query );
>
> This bean is put on the request for use in the results.jsp page.
>
> I'm able to quite a bit of work with the bean, determine hits, page
> counts, etc. except yank a document and display the indexed fields
> (I'm using the org.apache.lucene.demo.IndexHTML) such as "title",
> "summary", and "url".
>
> curr position: <%= searchBean.getHitsIterator().getCurrentPosition() %>
>
> <% if( searchBean.getHitsIterator().hasNext() ) {
> Document doc = searchBean.getHitsIterator().next(); // BOOM!
> }
> %>
>
> Any ideas? I only see K. Burton's FSDirectory patch in the archives,
> but nothing I don't have from CVS.
>
> Here's the stack trace:
>
> java.io.IOException: Bad file descriptor
> at java.io.RandomAccessFile.seek(Native Method)
> at
> org.apache.lucene.store.FSInputStream.readInternal(FSDirectory.java:
> 428)
> at org.apache.lucene.store.InputStream.refill(InputStream.java:196)
> at org.apache.lucene.store.InputStream.readByte(InputStream.java:81)
> at org.apache.lucene.store.InputStream.readInt(InputStream.java:111)
> at org.apache.lucene.store.InputStream.readLong(InputStream.java:134)
> at org.apache.lucene.index.FieldsReader.doc(FieldsReader.java:96)
> at
> org.apache.lucene.index.SegmentReader.document(SegmentReader.java:275)
> at org.apache.lucene.search.IndexSearcher.doc(IndexSearcher.java:107)
> at org.apache.lucene.search.Hits.doc(Hits.java:130)
> at org.apache.lucene.beans.HitsIterator.getDoc(HitsIterator.java:161)
> at org.apache.lucene.beans.HitsIterator.next(HitsIterator.java:139)
> at org.apache.jsp.results_jsp._jspService(results_jsp.java:117)
>
> ...
>
> Many thanks,
> Tim
>
> --
> /**
> * Timothy Stone . www.petmystone.com
> * Harrisburg PA . javafueled at petmystone.com
> * USA . coffee fueled macintosh zealot
> *
> * "This Satan's drink [coffee] is so
> * delicious, we shall cheat Satan and
> * baptize it."
> * --Pope Clement VIII
> */
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org