lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Wang" <john.w...@gmail.com>
Subject Re: [jira] Commented: (LUCENE-1473) Implement Externalizable in main top level searcher classes
Date Wed, 03 Dec 2008 00:22:48 GMT
If you guys need help, maybe you guys should expand your committer list?
"product speaks well for itself so far", from what I have heard, losta
people are just branching off the code-base and making changes and do merges
every release. I really don't want to do that here, but I am being forced
down that road. What I think should be avoided what happened to Linux, where
there are different versions of the kernel, e.g. there are different version
of lucene projects.

Don't get me wrong, I think it is one of the best projects out there. But
sometimes I think you guys should listen to the community a bit more,
instead of presuming how the product is used.

Anyway, thanks for looking into those issues.

-John

On Tue, Dec 2, 2008 at 4:11 PM, Mark Miller <markrmiller@gmail.com> wrote:

> I worked on getting both of thoses issues resolved :) Sorry, can't please
> everyone. If it helps, I'll commit that second one soon now that I can. It's
> lazy consensus around here man. Mabye it's not ideal, but I think the
> product speaks well for itself so far. I've never met a more accomadating
> group of guys myself. It is a large part volunteer effort.
>
> - Mark
>
> On Dec 2, 2008, at 7:02 PM, "John Wang" <john.wang@gmail.com> wrote:
>
> I have described our use-case in good detail. I think it is a common
> architecture. And we are not using RemoteSearcher. This problem is not tied
> to RemoteSearcher, and we are not using RMI. Serialized java objects can be
> used at places other than RMI.
> "sometime you IMp serializable for RMI but you don't want to fully support
> it. Mabye it's not great java, but it's common enough, and makes sense to me
> in  certain instances." - does not make sense to me. There are lotsa bugs
> that are common, e.g. thread-safety, dead-lock, memory leak, and they are
> bad java, doesn't mean they should not be addressed.
>
> Pardon me for being blunt, but this is really a bug: the expected behavior
> stated by the API is not honored. It would have been avoided if the same
> compiler was used for the release, with Java being WORA, this smells like a
> bug to me.
>
> My frustration is not unfounded, here are some examples I personally ran
> into:
>
> <https://issues.apache.org/jira/browse/LUCENE-1246>
> https://issues.apache.org/jira/browse/LUCENE-1246: simple 1 line null
> check, over 8 months, and still being "discussed"
>
> <https://issues.apache.org/jira/browse/SOLR-243>
> https://issues.apache.org/jira/browse/SOLR-243: with 4 votes, also few
> lines of change with the patch was originally done, over 18months, and still
> being "discussed"
>
> -John
>
> On Tue, Dec 2, 2008 at 3:43 PM, Mark Miller < <markrmiller@gmail.com>
> markrmiller@gmail.com> wrote:
>
>> Woah! I think you got the wrong impression. I think Doug said basically
>> what I was thinking (if not a bit more clearly than I was thinking it). I
>> think we are all open to any good patches. It's nice to understand and
>> discuss them first though.
>>
>> To reiterate what doug mentioned, sometime you IMp serializable for RMI
>> but you don't want to fully support it. Mabye it's not great java, but it's
>> common enough, and makes sense to me in  certain instances.
>>
>> - Mark
>>
>>
>>
>> On Dec 2, 2008, at 6:30 PM, "John Wang (JIRA)" < <jira@apache.org>
>> jira@apache.org> wrote:
>>
>>
>>>   [
>>> <https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652594#action_12652594>
>>> https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652594#action_12652594
>>>  ]
>>>
>>> John Wang commented on LUCENE-1473:
>>> -----------------------------------
>>>
>>> the fact an object implements Serializable implies this object can be
>>> serialized. It is a known good java programming practice to include a suid
>>> to the class (as a static variable) when the object declares itself to be
>>> Serializable. If it is not meant to be serialized, why did it implement
>>> Serializable. Furthermore, what is the reason to avoid it being serialized?
>>> I find the reason being the cost of support kinda ridiculous, seems this
>>> reason can be applied to any bug fix, because this at the end of the day, it
>>> is a bug.
>>>
>>> I don't understand the issue of "extra bytes" to the term dictionary if
>>> the Term instance is not actually serialized to the index (at least I really
>>> hope that is not done)
>>>
>>> The serialVersionUID (suid) is a long because it is a java thing. Here is
>>> a link to some information on the subject:
>>> <http://java.sun.com/developer/technicalArticles/Programming/serialization/>
>>> http://java.sun.com/developer/technicalArticles/Programming/serialization/
>>>
>>> Use case: deploying lucene in a distributed environment, we have a
>>> broker/server architecture. (standard stuff), we want roll out search
>>> servers with lucene 2.4 instance by instance. The problem is that the broker
>>> is sending a Query object to the searcher via java serialization at the
>>> server level, and the broker is running 2.3. And because of specifically
>>> this problem, 2.3 brokers cannot to talk to 2.4 search servers even when the
>>> Query object was not changed.
>>>
>>> To me, this is a very valid use-case. The problem was two different
>>> people did the release with different compilers.
>>>
>>> At the risk of pissing off the Lucene powerhouse, I feel I have to
>>> express some candor. I am growing more and more frustrated with the lack of
>>> the open source nature of this project and its unwillingness to work with
>>> the developer community. This is a rather trivial issue, and it is taking 7
>>> back-and-forth's to reiterate some standard Java behavior that has been
>>> around for years.
>>>
>>> Lucene is a great project and has enjoyed great success, and I think it
>>> is to everyone's interest to make sure Lucene grows in a healthy
>>> environment.
>>>
>>>
>>>
>>>  Implement Externalizable in main top level searcher classes
>>>> -----------------------------------------------------------
>>>>
>>>>               Key: LUCENE-1473
>>>>               URL: <https://issues.apache.org/jira/browse/LUCENE-1473>
>>>> https://issues.apache.org/jira/browse/LUCENE-1473
>>>>           Project: Lucene - Java
>>>>        Issue Type: Bug
>>>>        Components: Search
>>>>  Affects Versions: 2.4
>>>>          Reporter: Jason Rutherglen
>>>>          Priority: Minor
>>>>       Attachments: LUCENE-1473.patch
>>>>
>>>>
>>>> To maintain serialization compatibility between Lucene versions, major
>>>> classes can implement Externalizable.  This will make Serialization faster
>>>> due to no reflection required and maintain backwards compatibility.
>>>>
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: <java-dev-unsubscribe@lucene.apache.org>
>>> java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: <java-dev-help@lucene.apache.org>
>>> java-dev-help@lucene.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: <java-dev-unsubscribe@lucene.apache.org>
>> java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: <java-dev-help@lucene.apache.org>
>> java-dev-help@lucene.apache.org
>>
>>
>

Mime
View raw message