[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239260#comment-14239260 ] Jayson Minard commented on SOLR-4792: - I've added two tickets for Solr-Undertow to support this change: Bootstrap WAR download https://github.com/bremeld/solr-undertow/issues/11 Solr 5.0 support (documentation, location from which to bootstrap WAR) https://github.com/bremeld/solr-undertow/issues/12 stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239263#comment-14239263 ] Jayson Minard commented on SOLR-4792: - in distribution solr-webapp dir still exists, is that intentional? webapps contains the WAR but this old directory its stuck in the distribution. Should be removed yes? stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231524#comment-14231524 ] Jayson Minard commented on SOLR-4792: - Mark: so final understanding: WAR gone from maven, WAR gone from dist, but will remain in server/web-apps correct? stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4792) stop shipping a war in 5.0
[
https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229243#comment-14229243
]
Jayson Minard edited comment on SOLR-4792 at 12/1/14 8:29 AM:
--
{quote}
But if we remove it in 5, we can fix the rest of the usability issues in
5.1-5.3.
{quote}
I feel a half broken Solr 5.0 with expectations to fix later leaves a bad
impression. Similar to collection api's missing in Solr 4.4 and added
incrementally through Solr 4.10 leaving different functionality in each release
for things that should have been present in 4.4. Some users of Solr are slow to
upgrade and many have large important things missing because it is hard to find
a 'complete' release. I prefer not to propagate thus behaviour into Solr 5.x.
It is a big reason ElasticSearch gains ground.
was (Author: jayson.minard):
I feel a half broken Solr 5.0 with expectations to fix later leaves a bad
impression. Similar to collection api's missing in Solr 4.4 and added
incrementally through Solr 4.10 leaving different functionality in each release
for things that should have been present in 4.4. Some users of Solr are slow to
upgrade and many have large important things missing because it is hard to find
a 'complete' release. I prefer not to propagate thus behaviour into Solr 5.x.
It is a big reason ElasticSearch gains ground.
stop shipping a war in 5.0
--
Key: SOLR-4792
URL: https://issues.apache.org/jira/browse/SOLR-4792
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Assignee: Mark Miller
Fix For: 5.0, Trunk
Attachments: SOLR-4792.patch
see the vote on the developer list.
This is the first step: if we stop shipping a war then we are free to do
anything we want.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-4792: Comment: was deleted (was: Besides being Kotlin, what would you want to see different? ) stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4792) stop shipping a war in 5.0
[
https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229242#comment-14229242
]
Jayson Minard edited comment on SOLR-4792 at 12/1/14 8:34 AM:
--
{quote}
The solr-undertow is not in Java, right? I think I saw a Kotlin reference in
the docs.
{quote}
It is a stand alone component outside the main build and nothing depends on it
directly. Kotlin is fully interoperable in both directions with Java with a
tiny runtime. Stable. Performant. Uses undertow.io (written in Java). Easy
to read. And is better than start.sh which is not in Java nor the JVM. It is a
4MB component.
was (Author: jayson.minard):
'in Kotlin'... It is a stand alone component outside the main build. Fully
interoperable in both directions with Java. Stable. Performant. Uses
undertow which is Java. Easy to read. And is better than start.sh which is not
in Java nor the JVM.
I think is like 4.5mb in tar.gz with Kotlin runtime which is tiny.
stop shipping a war in 5.0
--
Key: SOLR-4792
URL: https://issues.apache.org/jira/browse/SOLR-4792
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Assignee: Mark Miller
Fix For: 5.0, Trunk
Attachments: SOLR-4792.patch
see the vote on the developer list.
This is the first step: if we stop shipping a war then we are free to do
anything we want.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[
https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229692#comment-14229692
]
Jayson Minard commented on SOLR-4792:
-
{quote}
Remove war from /dist but keep it in /server/webapps.
{quote}
Can we keep it (the WAR) in the maven produced artifacts and repo? that is the
easiest place to pull it by other tools, either at build time, runtime or for
users.
stop shipping a war in 5.0
--
Key: SOLR-4792
URL: https://issues.apache.org/jira/browse/SOLR-4792
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Assignee: Mark Miller
Fix For: 5.0, Trunk
Attachments: SOLR-4792.patch
see the vote on the developer list.
This is the first step: if we stop shipping a war then we are free to do
anything we want.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[
https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230497#comment-14230497
]
Jayson Minard commented on SOLR-4792:
-
{quote}
We have already discussed and had a vote. This issue is the result of that. The
vote and previous discussions are available in the archives.
{quote}
Well, the result of the vote did not end up in this issue. Only the break
Solr deployment for all users part seemed to have been recorded. And then
acted upon. Great. The archives are helpful for fun reading but don't fix the
problem.
{quote}
5 kind of came out of nowhere, and so this seemed the easiest transition path.
{quote}
easiest for whom?
{quote}
No, it won't be in maven - there will be no official WAR support.
{quote}
translation: make love, not WARs
How about, remove the WAR when something worthwhile has replaced the
functionality that people use in the app servers in which they host the WAR.
Even ElasticSearch provides Transport Wares so that people can use WAR
deployment, because in some places, it is just the rule of law. And you can
convince the laws to change, when you have something sufficiently manageable as
an alternative. Here, that is lacking. People trial this side by side with
ES, and one will look better.
I guess a follow-on list of activities is: someone create a solr-war-packaging
project outside the code base so that it is not official (I now have
https://github.com/bremeld/solr-in-a-war so will get on it based on current
trunk). and maybe someone write the JIRA issues for making the Solr runner
into a real project. Since that doesn't exist yet, I'll continue Solr-undertow
to help in the meantime. But would be nice if it was in the same direction as
what was intended rather than duplicate effort.
stop shipping a war in 5.0
--
Key: SOLR-4792
URL: https://issues.apache.org/jira/browse/SOLR-4792
Project: Solr
Issue Type: Task
Components: Build
Reporter: Robert Muir
Assignee: Mark Miller
Fix For: 5.0, Trunk
Attachments: SOLR-4792.patch
see the vote on the developer list.
This is the first step: if we stop shipping a war then we are free to do
anything we want.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230570#comment-14230570 ] Jayson Minard commented on SOLR-4792: - Last note, because I'm probably boring people... Keep it in Maven does not put it into the distribution but means that Solr doesn't have to be rebuilt just to create a WAR. if not in the .tar.gz and not publicized, but still available in Maven then other's can link to it, document it, include it in other projects as a dependency, etc. So if it is in server/webapps but not in /dist, then why not maven. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-4792: Comment: was deleted (was: Last note, because I'm probably boring people... Keep it in Maven does not put it into the distribution but means that Solr doesn't have to be rebuilt just to create a WAR. if not in the .tar.gz and not publicized, but still available in Maven then other's can link to it, document it, include it in other projects as a dependency, etc. So if it is in server/webapps but not in /dist, then why not maven.) stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230795#comment-14230795 ] Jayson Minard commented on SOLR-4792: - ok, so final understanding: WAR gone from maven, WAR gone from dist, but will remain in server/web-apps correct? stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229217#comment-14229217 ] Jayson Minard commented on SOLR-4792: - I would be willing to shore up. My Solr-undertow to use as a base. It is simpler, easy to configure, in production at two deployments of high scale (1500-1600 qps) using less threads and memory than jetty, out performed efforts of cloudera stack and did not need to break previous deployments by a war to accomplish this. My problem with this issue, to repeat what I said before, and others recently said today... Is that it is half the story, half baked. Without knowing what to do, it breaks things for no user benefit. Do you want to review Solr-undertow and provide feedback and I can merge it over. Without constraints of old params it can be even cleaner. It is further along than the startup scripts which really are not enough. And it has more thought into it than this issue appears to have. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229226#comment-14229226 ] Jayson Minard commented on SOLR-4792: - Note: Solr-undertow switches to blocking i/o when using servlet but also supports non blocking i/o for other resources such as the Web resources or future elements that are non blocking. And undertow is much easier library than Netty for a base. More functionality, easier API, high performance. Basis for Wildly the JBoss replacement. Modern. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229229#comment-14229229 ] Jayson Minard commented on SOLR-4792: - I see no value in removing war file. It is a documentation problem for deployment but us relied upon for users and isn't important to delete. Add the new 'ideal world' and overlap time to give a chance for devops to change, then delete. But probably is not important to delete once a better answer is present and the focus of documentation. I don't understand why this issue exists in absence of the fully baked answer. Or at least look at the existing implantation that solved this already. Raro stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229242#comment-14229242 ] Jayson Minard commented on SOLR-4792: - 'in Kotlin'... It is a stand alone component outside the main build. Fully interoperable in both directions with Java. Stable. Peromant. Uses undertow which is Java. Easy to read. And is better than start.sh which is not in Java nor the JVM. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229243#comment-14229243 ] Jayson Minard commented on SOLR-4792: - I feel a half broken Solr 5.0 with expectations to fix later leaves a bad impression. Similar to collection api's missing in Solr 4.4 and added incrementally through Solr 4.10 leaving different functionality in each release for things that should have been present in 4.4. Some users of Solr are slow to upgrade and many have large important things missing because it is hard to find a 'complete' release. I prefer not to propagate thus behaviour into Solr 5.x. It is a big reason ElasticSearch gains ground. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229242#comment-14229242 ] Jayson Minard edited comment on SOLR-4792 at 11/30/14 9:35 PM: --- 'in Kotlin'... It is a stand alone component outside the main build. Fully interoperable in both directions with Java. Stable. Performant. Uses undertow which is Java. Easy to read. And is better than start.sh which is not in Java nor the JVM. was (Author: jayson.minard): 'in Kotlin'... It is a stand alone component outside the main build. Fully interoperable in both directions with Java. Stable. Peromant. Uses undertow which is Java. Easy to read. And is better than start.sh which is not in Java nor the JVM. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229242#comment-14229242 ] Jayson Minard edited comment on SOLR-4792 at 11/30/14 9:37 PM: --- 'in Kotlin'... It is a stand alone component outside the main build. Fully interoperable in both directions with Java. Stable. Performant. Uses undertow which is Java. Easy to read. And is better than start.sh which is not in Java nor the JVM. I think is like 4.5mb in tar.gz with Kotlin runtime which is tiny. was (Author: jayson.minard): 'in Kotlin'... It is a stand alone component outside the main build. Fully interoperable in both directions with Java. Stable. Performant. Uses undertow which is Java. Easy to read. And is better than start.sh which is not in Java nor the JVM. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229250#comment-14229250 ] Jayson Minard commented on SOLR-4792: - Besides being Kotlin, what would you want to see different? stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14228855#comment-14228855 ] Jayson Minard commented on SOLR-4792: - Yup. Solr 5 is not a WAR. It's a search server application. or it is still what is was before, just the fact that it is servlet based is hidden now, and without the obvious option of alternative deployments. Regardless, I'll update solr-undertow (which already makes it a search server application by using the WAR outside of an application server) to work with a distribution archive instead of the packaged WAR. The WAR had less files than a full distribution which also includes examples so this makes Solr bigger. Would be nice if you do this that you make a clean distribution as well without any samples and just minimal placeholder files. Also with this change are the parameters for things like jetty.port, solr.home, solr.data going to be cleaned up and use something like a configuration file? or made more uniform and obvious in some way? This was something else I cleaned up in https://github.com/bremeld/solr-undertow using typesafe config. Maybe merge some of those ideas in and I can drop the separate project. But then again rate limiters to protect the server and other features might be missing... Also, we should review the thread and other settings that were previously recommended by Jetty if it is continued to be used, because they were excessive (10,000 will exceed most file limits set per user on boxes by default, and is unnecessarily high). Settings like this create a chance for the server to fail under high load rather than just slow down, it is more likely to crash. Also, multiple ports. One for internal communication, another for external, maybe another for updates different from queries, for admin. Helps to make sure that under load (eating the thread pool) a server still responds for other needs. If you take on responsibility to provide Solr as a server, it needs to start adding features around these other issues. Otherwise people will be configuring something in front of Solr to proxy and protect it, and then you might as well have stayed in a WAR so they could do it within the same process. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207518#comment-14207518 ] Jayson Minard commented on SOLR-4792: - This is unnecessary change. A WAR can be shipped and still be used in embedded runner while still retaining the ability to be configured and used in an application server. See: https://github.com/bremeld/solr-undertow Uses Undertow.io to create an easy to configure Solr (and SolrCloud) server by extracting the WAR to create the web site and the classpath then executes Solr embedded with a high performance server. And yet still retains the ability to add additional functionality such as request rate limiting (released), auth, ssl, other port configures, and other features in the future. I think the problem with WAR in the past is that there is little reasonable documentation for current Jetty, current Tomcat, current Wildfly for Solr, and most old resources on the internet are very old and dated on the topics for Solr. A small Doc effort, and killing these old outdated resources would go a long way to fixing that issue. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Robert Muir Fix For: Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207518#comment-14207518 ] Jayson Minard edited comment on SOLR-4792 at 11/12/14 2:01 AM: --- This is unnecessary change. A WAR can be shipped and still be used in embedded runner while still retaining the ability to be configured and used in an application server. See: https://github.com/bremeld/solr-undertow Uses Undertow.io to create an easy to configure Solr (and SolrCloud) server by extracting the WAR to create the web site and the classpath then executes Solr embedded with a high performance server. And yet still retains the ability to add additional functionality such as request rate limiting (released), auth, ssl, other port configures, and other features in the future due to capabilities of Undertow. I think the problem with WAR in the past is that there is little reasonable documentation for current Jetty, current Tomcat, current Wildfly for Solr, and most old resources on the internet are very old and dated on the topics for Solr. A small Doc effort, and killing these old outdated resources would go a long way to fixing that issue. Regardless, there are other options that keep a WAR while providing a simple to configure and start server that is as fast or faster than Jetty. (Solr-Undertow uses far fewer threads for the same throughput for one, and its configuration is more sane than the default Jetty configuration has been in the past) I am the author of Solr-Undertow but also a user of Solr with experience in almost every app server and deployment model possible; so this small project was a way to fix the problem while retaining war deployment. WAR deployment could use a simpler model and less environment variables. Maybe one -D system property to identify a configuration file (URL, that can be downloaded) would be a better model and easier to add to most Application server startups. was (Author: jayson.minard): This is unnecessary change. A WAR can be shipped and still be used in embedded runner while still retaining the ability to be configured and used in an application server. See: https://github.com/bremeld/solr-undertow Uses Undertow.io to create an easy to configure Solr (and SolrCloud) server by extracting the WAR to create the web site and the classpath then executes Solr embedded with a high performance server. And yet still retains the ability to add additional functionality such as request rate limiting (released), auth, ssl, other port configures, and other features in the future. I think the problem with WAR in the past is that there is little reasonable documentation for current Jetty, current Tomcat, current Wildfly for Solr, and most old resources on the internet are very old and dated on the topics for Solr. A small Doc effort, and killing these old outdated resources would go a long way to fixing that issue. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Robert Muir Fix For: Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in trunk (6.0)
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207594#comment-14207594 ] Jayson Minard commented on SOLR-4792: - I agree with the comments from the mailing list, and they are not mutually exclusive with a WAR. I'm not sure we need a WAR, but you can always adapt to one (as an example, ElasticSearch for example has elasticsearch-transport-wares to do this) App servers don't prevent better ways of doing configuration, and usually everything needs at least a starting point to find a configuration whether it is a war or a command-line tool. It can be available for both. Not that I'm all pro WAR anyway since I obviously moved away from it myself, but there are already solutions that make it easier while it is still a WAR. That is just a bundling of everything needed to run... Either way, it should be easier to configure and use. stop shipping a war in trunk (6.0) -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Robert Muir Fix For: Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in trunk (6.0)
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207595#comment-14207595 ] Jayson Minard commented on SOLR-4792: - I agree with the comments from the mailing list, and they are not mutually exclusive with a WAR. I'm not sure we need a WAR, but you can always adapt to one (as an example, ElasticSearch for example has elasticsearch-transport-wares to do this) App servers don't prevent better ways of doing configuration, and usually everything needs at least a starting point to find a configuration whether it is a war or a command-line tool. It can be available for both. Not that I'm all pro WAR anyway since I obviously moved away from it myself, but there are already solutions that make it easier while it is still a WAR. That is just a bundling of everything needed to run... Either way, it should be easier to configure and use. On Wed, Nov 12, 2014 at 12:14 AM, Shawn Heisey (JIRA) j...@apache.org stop shipping a war in trunk (6.0) -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Robert Muir Fix For: Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4792) stop shipping a war in trunk (6.0)
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207596#comment-14207596 ] Jayson Minard commented on SOLR-4792: - For 6.0 can we please create issues for the things we DO WANT instead of just no war ... as you say, the title here is bad and it isn't an actionable list of issues to reach the goals from the mailing list vote. stop shipping a war in trunk (6.0) -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Robert Muir Fix For: Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2193) Re-architect Update Handler
[ https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019953#comment-13019953 ] Jayson Minard commented on SOLR-2193: - Some of this was already solved in: https://issues.apache.org/jira/browse/SOLR-1155 (locking and re-opening index writer were fixed) Re-architect Update Handler --- Key: SOLR-2193 URL: https://issues.apache.org/jira/browse/SOLR-2193 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.0 Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch The update handler needs an overhaul. A few goals I think we might want to look at: 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler, DefaultUpdateHandler 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what we now do with special casing: if (directupdatehandler2) success else failish 3. Stop closing the IndexWriter and start using commit (still lazy IW init though). 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. 5. Keep NRT support in mind. 6. Keep microsharding in mind (maintain logical index as multiple physical indexes) 7. Address the current issues we face because multiple original/'reloaded' cores can have a different IndexWriter on the same index. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019954#comment-13019954 ] Jayson Minard commented on SOLR-1155: - Thank Yonik, I'll take a look at his to see if there was anything I learned that applies. This SOLR-1155 has been used in heavy production load and is very stable against 1.4 so maybe Mark will take a peek, I posted a note on the other issue as well. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3, 1.4 Reporter: Jayson Minard Fix For: Next Attachments: SOLR-1155-release1.4-rev834789.patch, SOLR-1155-trunk-rev834706.patch, Solr-1155.patch, Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019955#comment-13019955 ] Jayson Minard commented on SOLR-1155: - I'll look at updating this for 3.1 for those that need it on that release, and Mark's looks good for 4.x and beyond. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3, 1.4 Reporter: Jayson Minard Fix For: Next Attachments: SOLR-1155-release1.4-rev834789.patch, SOLR-1155-trunk-rev834706.patch, Solr-1155.patch, Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2193) Re-architect Update Handler
[ https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019961#comment-13019961 ] Jayson Minard commented on SOLR-2193: - Since SOLR-1155 is probably an easier change for Solr 3.1 due to its ancestry, so to get the same benefits I'll work to update it for that version, assuming this patch of yours is for 4.x onwards. Re-architect Update Handler --- Key: SOLR-2193 URL: https://issues.apache.org/jira/browse/SOLR-2193 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.0 Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch The update handler needs an overhaul. A few goals I think we might want to look at: 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler, DefaultUpdateHandler 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what we now do with special casing: if (directupdatehandler2) success else failish 3. Stop closing the IndexWriter and start using commit (still lazy IW init though). 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. 5. Keep NRT support in mind. 6. Keep microsharding in mind (maintain logical index as multiple physical indexes) 7. Address the current issues we face because multiple original/'reloaded' cores can have a different IndexWriter on the same index. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016382#comment-13016382 ] Jayson Minard commented on SOLR-1155: - Is there interest in me updating this for 3.1? It is a huge performance improvement over DirectUpdateHandler2 under heavy indexing load... Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3, 1.4 Reporter: Jayson Minard Fix For: Next Attachments: SOLR-1155-release1.4-rev834789.patch, SOLR-1155-trunk-rev834706.patch, Solr-1155.patch, Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (SOLR-1752) SolrJ fails with exception when passing document ADD and DELETEs in the same request using XML request writer (but not binary request writer)
SolrJ fails with exception when passing document ADD and DELETEs in the same
request using XML request writer (but not binary request writer)
-
Key: SOLR-1752
URL: https://issues.apache.org/jira/browse/SOLR-1752
Project: Solr
Issue Type: Bug
Components: clients - java, update
Affects Versions: 1.4
Reporter: Jayson Minard
Priority: Blocker
Add this test to SolrExampleTests.java and it will fail when using the XML
Request Writer (now default), but not if you change the SolrExampleJettyTest to
use the BinaryRequestWriter.
{code}
public void testAddDeleteInSameRequest() throws Exception {
SolrServer server = getSolrServer();
SolrInputDocument doc3 = new SolrInputDocument();
doc3.addField( id, id3, 1.0f );
doc3.addField( name, doc3, 1.0f );
doc3.addField( price, 10 );
UpdateRequest up = new UpdateRequest();
up.add( doc3 );
up.deleteById(id001);
up.setWaitFlush(false);
up.setWaitSearcher(false);
up.process( server );
}
{code}
terminates with exception:
{code}
Feb 3, 2010 8:55:34 AM org.apache.solr.common.SolrException log
SEVERE: org.apache.solr.common.SolrException: Illegal to have multiple roots
(start tag in epilog?).
at [row,col {unknown-source}]: [1,125]
at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:72)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:54)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:835)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:723)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:202)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: com.ctc.wstx.exc.WstxParsingException: Illegal to have multiple
roots (start tag in epilog?).
at [row,col {unknown-source}]: [1,125]
at
com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:630)
at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:461)
at
com.ctc.wstx.sr.BasicStreamReader.handleExtraRoot(BasicStreamReader.java:2155)
at
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2070)
at
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2647)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1019)
at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:90)
at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:69)
... 18 more
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LUCENE-2171) Over synchronization for read-only index readers in SegmentTermDocs
Over synchronization for read-only index readers in SegmentTermDocs
---
Key: LUCENE-2171
URL: https://issues.apache.org/jira/browse/LUCENE-2171
Project: Lucene - Java
Issue Type: Improvement
Components: Search
Affects Versions: 3.0, 2.9.1
Reporter: Jayson Minard
Priority: Minor
In SegmentTermDocs constructor (from 2.9.1)
{code}
46protected SegmentTermDocs(SegmentReader parent) {
47 this.parent = parent;
48 this.freqStream = (IndexInput) parent.core.freqStream.clone();
49 synchronized (parent) {
50this.deletedDocs = parent.deletedDocs;
51 }
52 this.skipInterval = parent.core.getTermsReader().getSkipInterval();
53 this.maxSkipLevels =
parent.core.getTermsReader().getMaxSkipLevels();
54}
{code}
The synchronization on parent for accessing deletedDocs is unnecessary on
readonly indexes. If that access was moved into the SegmentReader then it
could be protected there by default and overridden in ReadonlySegmentReader.
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (SOLR-1162) SolrJ UpdateRequest does not maintain order of operations when sending mixed types of changes (updates, delete id, delete query, update iterator)
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12776829#action_12776829 ] Jayson Minard commented on SOLR-1162: - Yikes, set to 1.5 -- I better revamp this to current code. SolrJ UpdateRequest does not maintain order of operations when sending mixed types of changes (updates, delete id, delete query, update iterator) - Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Fix For: 1.5 Attachments: Solr-1162.patch, Solr-1162.patch, Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155-trunk-rev834706.patch Updated patch to trunk rev 834706 and up to date with current DirectUpdateHandler2 functionality Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3, 1.4 Reporter: Jayson Minard Attachments: SOLR-1155-trunk-rev834706.patch, Solr-1155.patch, Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Affects Version/s: 1.4 Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3, 1.4 Reporter: Jayson Minard Attachments: SOLR-1155-trunk-rev834706.patch, Solr-1155.patch, Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155-release1.4-rev834789.patch Added patch for release version of 1.4 (but this is most likely identical to the last trunk patch anyway) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3, 1.4 Reporter: Jayson Minard Attachments: SOLR-1155-release1.4-rev834789.patch, SOLR-1155-trunk-rev834706.patch, Solr-1155.patch, Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1299) In distributed search cannot search on any schema field in ascending order (descending is OK)
[ https://issues.apache.org/jira/browse/SOLR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12734681#action_12734681 ] Jayson Minard commented on SOLR-1299: - Shalin, Are you picking this one up, or should we try to dig into it? Not an area I'm familiar with but can start tracing through... In distributed search cannot search on any schema field in ascending order (descending is OK) - Key: SOLR-1299 URL: https://issues.apache.org/jira/browse/SOLR-1299 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.4 Reporter: David Bowen Fix For: 1.4 Using the example with some of the exampledocs posted, the url: http://localhost:8983/solr/select/?q=*:*sort=timestamp+descfsv=true works correctly, but change desc to asc and you get: HTTP ERROR: 500 null java.lang.NullPointerException at org.apache.solr.handler.component.QueryComponent.getComparator(QueryComponent.java:284) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:229) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) at com.proquest.magnolia.solr.plugins.SummonSearchHandler.handleRequestBody(SummonSearchHandler.java:19) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1164) BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format
[ https://issues.apache.org/jira/browse/SOLR-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712128#action_12712128 ] Jayson Minard commented on SOLR-1164: - The UpdateRequest has get methods for getting the individual lists back that can be deprecated but harder to implement their replacement with everything lumped together. So could go either way on that one. Will look at options there when I get back to updating that patch soon. BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format - Key: SOLR-1164 URL: https://issues.apache.org/jira/browse/SOLR-1164 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Reporter: Jayson Minard Assignee: Noble Paul Attachments: SOLR-1164.patch, SOLR-1164.patch When sending commands in the Java binary format to the BinaryUpdateRequestHandler it does not process them in the order received. It processes all add/updates then delete by id then delete by query regardless of what is sent. See SOLR-1162 for related issue and patch that covers both issues (they are intertwined since some classes are shared on both sides of the wire) I wanted a separate issue covering this so that it is seen from the server viewpoint and not just as a client API issue as other clients writing the binary form would be unable to maintain order of commands as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1164) BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format
[ https://issues.apache.org/jira/browse/SOLR-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711318#action_12711318 ] Jayson Minard commented on SOLR-1164: - So I need to take this patch, then fix SOLR-1162 over the top of it, correct? I'll see what changed across the two and make sure SOLR-1162 depends on this patch and is only the changes beyond it. BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format - Key: SOLR-1164 URL: https://issues.apache.org/jira/browse/SOLR-1164 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Reporter: Jayson Minard Assignee: Noble Paul Attachments: SOLR-1164.patch, SOLR-1164.patch When sending commands in the Java binary format to the BinaryUpdateRequestHandler it does not process them in the order received. It processes all add/updates then delete by id then delete by query regardless of what is sent. See SOLR-1162 for related issue and patch that covers both issues (they are intertwined since some classes are shared on both sides of the wire) I wanted a separate issue covering this so that it is seen from the server viewpoint and not just as a client API issue as other clients writing the binary form would be unable to maintain order of commands as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1162) SolrJ UpdateRequest does not maintain order of operations when sending mixed types of changes (updates, delete id, delete query, update iterator)
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12709390#action_12709390 ] Jayson Minard commented on SOLR-1162: - UpdateRequest is used on both ends of the stream potentially so we would want to break out the server pieces to not use the same un-ordered object for binary codec. I could go either way, just never saw a need for unordered to remain but then again there is a whole community out there that might! SolrJ UpdateRequest does not maintain order of operations when sending mixed types of changes (updates, delete id, delete query, update iterator) - Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1162.patch, Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1162) SolrJ UpdateRequest does not maintain order of operations when sending mixed types of changes (updates, delete id, delete query, update iterator)
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1162: Attachment: Solr-1162.patch Updated patch to remove return value from the unmarshall call as suggested above. SolrJ UpdateRequest does not maintain order of operations when sending mixed types of changes (updates, delete id, delete query, update iterator) - Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1162.patch, Solr-1162.patch, Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1162) SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1162: Attachment: Solr-1162.patch First round of patch, changed the UpdateRequest to maintain one list of different types of request items, then changed XML serialization to keep the same order, and the same for binary codec. Then updated the streaming side of the binary update handler to stream all request types (not just doc adds) and updated the unit test to verify order is maintained both when streaming or not streaming using the binary codec. SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk --- Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: SOLR-1155.patch) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: SOLR-1155.patch) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: SOLR-1155.patch) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: Solr-1155.patch Cleaning the patch so that RequestHandlerBase only has the required change and not the accidental reformatting. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: SOLR-1155.patch) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: SOLR-1155.patch) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: SOLR-1155.patch) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: SOLR-1155.patch) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: SOLR-1155.patch) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: SOLR-1155.patch) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: SOLR-1155.patch) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1162) SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708789#action_12708789 ] Jayson Minard commented on SOLR-1162: - In response to Noble Paul: An UpdateRequest currently contains: a list of adds, a single add via iterator, a list of delete by ids, a list of delete queries. So you can pile them all into the same object currently and then have no idea what order they will actually execute. If you want to stream adds, you cannot intermix deletes or other actions in the same stream. So if UpdateRequest is going to allow a set of different actions it should at least maintain the order in which they were added and execute them similarly. UpdateRequest is the current batching model, so it should be correct. SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk --- Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1162) SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1162: Issue Type: Improvement (was: Bug) SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk --- Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1162) SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708792#action_12708792 ] Jayson Minard commented on SOLR-1162: - Also (for Noble Paul)... UpdateRequest is the invoker of itself via the process method, there is nothing to which you can pass it as a list. UpdateRequest req = new UpdateRequest(); ... add things req.process(solrServer); SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk --- Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1162) SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1162: Attachment: Solr-1162.patch Updated patch to fix commitWithin parameter in UpdateRequest and failing unit test. SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk --- Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1162.patch, Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708795#action_12708795 ] Jayson Minard commented on SOLR-1155: - TODO: fix commitWithin, it isn't respected by the DirectUpdateHandler3 Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1162) SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708930#action_12708930 ] Jayson Minard commented on SOLR-1162: - Multiple requests are less efficient than sending large batches together. To be the most efficient with large requests, every user of SolrJ UpdateRequest would need to write the same logic... Place adds into UpdateRequest until you hit the first non-add, then send the UpdateRequest and start writing your deletes until you hit a non-delete, then flush the UpdateRequest and keep adding your new transaction type until you hit the first ... In that case they should avoid using UpdateRequest altogether as calling the SolrServer directly is just as easy. If we are going to batch on their behalf why wouldn't we do it correctly and be predictable with our ordering. I'm sure if JDBC batches did not maintain order, there would be havoc to pay... Besides that, it isn't clear to users of UpdateRequest as to the order of operations, so someone doing an Add doc 1, Delete doc 1, Add doc 1 may not end up with the expected outcome. It turns into Add doc 1, Add doc 1, Delete doc1 when streaming and similary for XML version of the transaction. If I did a Delete Query *:* then Add doc1, Add doc 2 I end up with no docs as the delete query comes last, but I (the user) does not know that. I've written code to work around UpdateRequest ordering and I usually end up only using it for commitWithin or having a commit tacked on the end of the request due to the above issues. SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk --- Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1162.patch, Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: Solr-1155.patch Resolve TODO for commitWithin, and updated AutoCommitTrackerTest to validate the fix. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1155.patch, Solr-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1162) SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12709037#action_12709037 ] Jayson Minard commented on SOLR-1162: - Outside of UpdateRequest if you hand construct a binary codec stream to send to Solr (without this patch) your order of actions would not be maintained within the stream. So the binary streaming update handler is broken in this regard as well. So this patch actually resolves two issue: UpdateRequest does not serialize into xml or binary stream the actions in-order. Nor does BinaryUpdateRequestHandler nor did the underlaying JavaBinUpdateRequestCodec so these all become unusable for mixed style actions since none can maintain order. UpdateRequest is just one of the clients to that server-side code that also has the same issue. SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk --- Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1162.patch, Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1162) SolrJ UpdateRequest does not maintain order of operations when sending mixed types of changes (updates, delete id, delete query, update iterator)
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1162: Description: In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. was:In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. Summary: SolrJ UpdateRequest does not maintain order of operations when sending mixed types of changes (updates, delete id, delete query, update iterator) (was: SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk) SolrJ UpdateRequest does not maintain order of operations when sending mixed types of changes (updates, delete id, delete query, update iterator) - Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard Attachments: Solr-1162.patch, Solr-1162.patch In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1164) BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format
BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format - Key: SOLR-1164 URL: https://issues.apache.org/jira/browse/SOLR-1164 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Reporter: Jayson Minard When sending commands in the Java binary format to the BinaryUpdateRequestHandler it does not process them in the order received. It processes all add/updates then delete by id then delete by query regardless of what is sent. See SOLR-1162 for related issue and patch that covers both issues (they are intertwined since some classes are shared on both sides of the wire) I wanted a separate issue covering this so that it is seen from the server viewpoint and not just as a client API issue as other clients writing the binary form would be unable to maintain order of commands as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1164) BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format
[ https://issues.apache.org/jira/browse/SOLR-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12709050#action_12709050 ] Jayson Minard commented on SOLR-1164: - Noticed that SolrJ classes are used in the server to implement the handler side which makes it hard to split the patch. If we want to clean that up, the patch can be split but otherwise leaving it in SOLR-1162 and tracking both sides of the coin by leaving this issue here. BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format - Key: SOLR-1164 URL: https://issues.apache.org/jira/browse/SOLR-1164 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Reporter: Jayson Minard When sending commands in the Java binary format to the BinaryUpdateRequestHandler it does not process them in the order received. It processes all add/updates then delete by id then delete by query regardless of what is sent. See SOLR-1162 for related issue and patch that covers both issues (they are intertwined since some classes are shared on both sides of the wire) I wanted a separate issue covering this so that it is seen from the server viewpoint and not just as a client API issue as other clients writing the binary form would be unable to maintain order of commands as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155.patch Updated unit test to compile (was missing method change from previous patch that changed an interface it implemented) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1162) SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk
SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk --- Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1162) SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk
[ https://issues.apache.org/jira/browse/SOLR-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708655#action_12708655 ] Jayson Minard commented on SOLR-1162: - Working on this patch now... SolrJ does not maintain order of operations when using an UpdateRequest object to send them in bulk --- Key: SOLR-1162 URL: https://issues.apache.org/jira/browse/SOLR-1162 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Jayson Minard In SolrJ UpdateRequest object it maintains separate lists of documents to add, delete, and delete queries so that the order of those operations is not known to the caller. It really should execute the items in the same order they were added to the UpdateRequest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155.patch minor change to rollback to only drop and re-open writer if there was one to begin wtih. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155.patch Knocked down a few TODO and cleaned up resetting of counts. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155.patch Bug fixing, and added a new test that test just the AutoCommitTracker in isolation rather than through the DirectUpdateHandlerX Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155.patch Change openWriter to do a check of null writer before locking to avoid artificial contention between threads due to ensuring a writer is open. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1157) Change for timeouts in RequestHandlerBase (rev674249) broke unit tests due to rsp.getResponse() returning null
Change for timeouts in RequestHandlerBase (rev674249) broke unit tests due to
rsp.getResponse() returning null
--
Key: SOLR-1157
URL: https://issues.apache.org/jira/browse/SOLR-1157
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Jayson Minard
Priority: Critical
This code:
code
boolean timedOut = (Boolean) rsp.getResponseHeader().get(partialResults) ==
null ? false : (Boolean) rsp.getResponseHeader().get(partialResults);
if (timedOut) {
numTimeouts++;
rsp.setHttpCaching(false);
}
/code
in RequestHandlerBase around line 128 breaks unit tests. Needs a null check on
getResponseHeader() before going further.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155.patch DirectUpdateHandlerWithAutoCommit.java DirectUpdateHandler3.java Updated file, and associated interface used to help DirectUpdateHandler2 and 3 co-exist with tests, SnapPuller and ReplicationHandler classes. A larger patch with all changes to tests, config files, and other items makeing DirectUpdateHandler3 the default (purely for running all of the unit tests using it) is attached as well. Patch includes fix for SOLR-1157 which got in the way of running unit tests. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: DirectUpdateHandler3.java, DirectUpdateHandler3.java, DirectUpdateHandler3.java, DirectUpdateHandlerWithAutoCommit.java, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707636#action_12707636 ] Jayson Minard commented on SOLR-1155: - All tests pass with the attached patch file and DirectUpdateHandler3 as the handler for each solrconfig variant in the test-files directory. Needs review for locking holes and some of the TODO comments answered still. And needs a lot of concurrent update testing. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: DirectUpdateHandler3.java, DirectUpdateHandler3.java, DirectUpdateHandler3.java, DirectUpdateHandlerWithAutoCommit.java, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707672#action_12707672 ] Jayson Minard commented on SOLR-1155: - Things likely needing further work: * serialize commits? (two shouldn't happen at same time) * optimize should us iwManageWriter lock from optimize through call-back call, so break it away from commit which only needs iwUseWriter?) This also takes care of the contract that optimize callback is still on an optimized index. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: DirectUpdateHandler3.java, DirectUpdateHandler3.java, DirectUpdateHandler3.java, DirectUpdateHandlerWithAutoCommit.java, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155.patch Fixed some of the issue mentioned in the comment above. Split commit and optimize work out since optimize has a stronger need to lock and be consistent. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: DirectUpdateHandler3.java) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: DirectUpdateHandlerWithAutoCommit.java) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: DirectUpdateHandler3.java) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: (was: DirectUpdateHandler3.java) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707692#action_12707692 ] Jayson Minard commented on SOLR-1155: - new TODO... Right now auto commit will eventually fire off a commit that might run into a manual commit or optimize and sit at the syncrhonization block, then fire off on the tail of the other action. I would rather it wait until those running commands clear and THEN evaluate if it needs to do a commit or not since its information it used to make the decision could be moot due to the other action that beat it in. So if a commit or optimize is running it will not evaluate for auto commit until they complete. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155.patch New patch resolves the serialization of commit/optimize/close/rollback actions that should not be concurrent with each other. Also protect methods after close to keep other threads from accidentally re-opening writer. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707701#action_12707701 ] Jayson Minard commented on SOLR-1155: - Does anyone know if the UpdateHandler.close() method is called when everything else is shut down and no transactions can come through? If so, I can remove the blocking added to prevent a writer from re-opening after close is called. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: SOLR-1155.patch move wait for searcher out of locks in optimize and commit Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch, SOLR-1155.patch Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707572#action_12707572 ] Jayson Minard commented on SOLR-1155: - This will involve a change to locking as seen in the thread mentioned above between add/delete/commit methods, but there are also synchronized methods on the CommitTracker scehduleCommitWithin method, run method, and getCommitCount method that will cause similar blocking. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707572#action_12707572 ] Jayson Minard edited comment on SOLR-1155 at 5/8/09 7:52 PM: - This will involve a change to locking as seen in the thread mentioned above between add/delete/commit methods, but there are also synchronized methods on the CommitTracker scehduleCommitWithin method, run method, and getCommitCount method that will cause similar blocking at least for deletes. was (Author: jminard): This will involve a change to locking as seen in the thread mentioned above between add/delete/commit methods, but there are also synchronized methods on the CommitTracker scehduleCommitWithin method, run method, and getCommitCount method that will cause similar blocking. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707600#action_12707600 ] Jayson Minard commented on SOLR-1155: - Thinking about pending counts as well. If adds are ongoing during a commit, there has to be a point in time where the counters clear the number of documents committed. Currently they are set to 0 which is safe since nothing was ongoing while the commit happened. Something to remember... Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707602#action_12707602 ] Jayson Minard commented on SOLR-1155: - Preparing a first patch, calling it DirectUpdateHandler3 as there is a lot of reshuffling and a new commit tracker implementation that is lighter-weight. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: DirectUpdateHandler3.java I created DirectUpdateHandler3 as a copy of DirectUpdateHandler2 and then did a pass across it rebuilding the locking, stats, and tracker. I am basically at the IDE show no errors stage and going to read it a few more times, and start testing. Feedback is welcome as I'm in the dark on a few areas of this code and I am working from a lot of assumptions. Some event placeholder methods remain while I think through the issues, will trim it back when done. Events to the auto commit tracker are within the locks to help avoid cases where we set the counts to 0 after other work has concurrently been done. The stats information has similar concerns and is not yet dealt with, so some stats might reset to 0 on commit when there was further work being done (so they should not go to 0). Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: DirectUpdateHandler3.java Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1155) Change DirectUpdateHandler2 to allow concurrent adds during an autocommit
[ https://issues.apache.org/jira/browse/SOLR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayson Minard updated SOLR-1155: Attachment: DirectUpdateHandler3.java Updated with different locking around the post commit/optimize handlers. There is a gap in time between commit and these calls, is that safe? left TODO's in the code at places of concern. Change DirectUpdateHandler2 to allow concurrent adds during an autocommit - Key: SOLR-1155 URL: https://issues.apache.org/jira/browse/SOLR-1155 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Jayson Minard Attachments: DirectUpdateHandler3.java, DirectUpdateHandler3.java Currently DirectUpdateHandler2 will block adds during a commit, and it seems to be possible with recent changes to Lucene to allow them to run concurrently. See: http://www.nabble.com/Autocommit-blocking-adds---AutoCommit-Speedup--td23435224.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1111) fix FieldCache usage in Solr
[ https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705414#action_12705414 ] Jayson Minard commented on SOLR-: - Is this Lucene version in the current 1.4 trunk, or is it a version not-yet integrated into Solr libs? And also, the description makes it sound like an upgrade issue, but really any 1.4 version could blow up due to this problem. Lastly, define blow up... Uses double memory, or some other side effect? fix FieldCache usage in Solr Key: SOLR- URL: https://issues.apache.org/jira/browse/SOLR- Project: Solr Issue Type: Bug Reporter: Yonik Seeley Fix For: 1.4 Recent changes in Lucene have altered how the FieldCache is used and as-is could lead to previously working Solr installations blowing up when they upgrade to 1.4. We need to fix, or document the affects of these changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1030) Facet counts are not correct (or total document count is not correct as they do not match) on some searches
Facet counts are not correct (or total document count is not correct as they do
not match) on some searches
---
Key: SOLR-1030
URL: https://issues.apache.org/jira/browse/SOLR-1030
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Jayson Minard
There isn't much detailed evidence for this one yet, but hopefully it rings a
bell with someone who made changes in this area recently...
Since updating to the tip from our previous use of the tip from around Jan 9,
2009 we are now seeing facet counts no longer match total document count. This
is through distributed search and I have not verified that it only happens on
distributed vs. single shard search so it could be on both.
For example, on a single valued field with one facet value set as a fq filter,
combined with a text search on a simple term science, the following is the
facet count:
8,294,284
And the total document count for the same results is:
8,294,274
some debug info (not sure why the filter query is replicated more than once,
but that shouldn't be harmful):
{code}
uerystring (science)
QParser OldLuceneQParser
filter_queries [sys_content_type:(Journal Article),
sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article)]
rawquerystring (science)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1030) Facet counts are not correct (or total document count is not correct as they do not match) on some searches
[
https://issues.apache.org/jira/browse/SOLR-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675405#action_12675405
]
Jayson Minard commented on SOLR-1030:
-
The last known working revision should be 733,656 as that includes patches we
passed through Shalin and counts matched at that time.
Facet counts are not correct (or total document count is not correct as they
do not match) on some searches
---
Key: SOLR-1030
URL: https://issues.apache.org/jira/browse/SOLR-1030
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Jayson Minard
There isn't much detailed evidence for this one yet, but hopefully it rings a
bell with someone who made changes in this area recently...
Since updating to the tip from our previous use of the tip from around Jan 9,
2009 we are now seeing facet counts no longer match total document count.
This is through distributed search and I have not verified that it only
happens on distributed vs. single shard search so it could be on both.
For example, on a single valued field with one facet value set as a fq
filter, combined with a text search on a simple term science, the following
is the facet count:
8,294,284
And the total document count for the same results is:
8,294,274
some debug info (not sure why the filter query is replicated more than once,
but that shouldn't be harmful):
{code}
uerystring(science)
QParser OldLuceneQParser
filter_queries[sys_content_type:(Journal Article),
sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article)]
rawquerystring(science)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1030) Facet counts are not correct (or total document count is not correct as they do not match) on some searches
[
https://issues.apache.org/jira/browse/SOLR-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675406#action_12675406
]
Jayson Minard commented on SOLR-1030:
-
Possible commits that could impact this area of Solr:
Rev 738606 - Upgrade to Lucene 2.9-dev r738345 by Yonik
Rev 738950 - Upgrade to Lucene 2.9-dev r738622 by Yonik
Rev 739305 - Revert to r738218 of Lucene by Yonik
Rev 740319 - Change SolrIndexSearcher to use insertWithOverflow by Yonik
Rev 741710 - Addition of timeouts for distrubted searching by Shalin (maybe we
time out on some shards?)
Rev 742988 - Make QueryComponent Optional by gsingers
Rev 743196 - Current lucene libs, SolrIndexReader introduction for
FileFloatSource fix by Yonik
So possibly a Lucene bug?
Facet counts are not correct (or total document count is not correct as they
do not match) on some searches
---
Key: SOLR-1030
URL: https://issues.apache.org/jira/browse/SOLR-1030
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Jayson Minard
There isn't much detailed evidence for this one yet, but hopefully it rings a
bell with someone who made changes in this area recently...
Since updating to the tip from our previous use of the tip from around Jan 9,
2009 we are now seeing facet counts no longer match total document count.
This is through distributed search and I have not verified that it only
happens on distributed vs. single shard search so it could be on both.
For example, on a single valued field with one facet value set as a fq
filter, combined with a text search on a simple term science, the following
is the facet count:
8,294,284
And the total document count for the same results is:
8,294,274
some debug info (not sure why the filter query is replicated more than once,
but that shouldn't be harmful):
{code}
uerystring(science)
QParser OldLuceneQParser
filter_queries[sys_content_type:(Journal Article),
sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article)]
rawquerystring(science)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1030) Facet counts are not correct (or total document count is not correct as they do not match) on some searches
[
https://issues.apache.org/jira/browse/SOLR-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675415#action_12675415
]
Jayson Minard commented on SOLR-1030:
-
The data is static, no updates.
Facet counts are not correct (or total document count is not correct as they
do not match) on some searches
---
Key: SOLR-1030
URL: https://issues.apache.org/jira/browse/SOLR-1030
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Jayson Minard
There isn't much detailed evidence for this one yet, but hopefully it rings a
bell with someone who made changes in this area recently...
Since updating to the tip from our previous use of the tip from around Jan 9,
2009 we are now seeing facet counts no longer match total document count.
This is through distributed search and I have not verified that it only
happens on distributed vs. single shard search so it could be on both.
For example, on a single valued field with one facet value set as a fq
filter, combined with a text search on a simple term science, the following
is the facet count:
8,294,284
And the total document count for the same results is:
8,294,274
some debug info (not sure why the filter query is replicated more than once,
but that shouldn't be harmful):
{code}
uerystring(science)
QParser OldLuceneQParser
filter_queries[sys_content_type:(Journal Article),
sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article)]
rawquerystring(science)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1030) Facet counts are not correct (or total document count is not correct as they do not match) on some searches
[
https://issues.apache.org/jira/browse/SOLR-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675416#action_12675416
]
Jayson Minard commented on SOLR-1030:
-
And the data hasn't changed since the last version of Solr was used (roughly
r733656) and either no one noticed it before, or the problem didn't previously
exist. Checking now for timeouts in the logs.
Facet counts are not correct (or total document count is not correct as they
do not match) on some searches
---
Key: SOLR-1030
URL: https://issues.apache.org/jira/browse/SOLR-1030
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Jayson Minard
There isn't much detailed evidence for this one yet, but hopefully it rings a
bell with someone who made changes in this area recently...
Since updating to the tip from our previous use of the tip from around Jan 9,
2009 we are now seeing facet counts no longer match total document count.
This is through distributed search and I have not verified that it only
happens on distributed vs. single shard search so it could be on both.
For example, on a single valued field with one facet value set as a fq
filter, combined with a text search on a simple term science, the following
is the facet count:
8,294,284
And the total document count for the same results is:
8,294,274
some debug info (not sure why the filter query is replicated more than once,
but that shouldn't be harmful):
{code}
uerystring(science)
QParser OldLuceneQParser
filter_queries[sys_content_type:(Journal Article),
sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article)]
rawquerystring(science)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1030) Facet counts are not correct (or total document count is not correct as they do not match) on some searches
[
https://issues.apache.org/jira/browse/SOLR-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675417#action_12675417
]
Jayson Minard commented on SOLR-1030:
-
Logs on aggregator instance of Solr show no exceptions. Logs on query slaves
show no exceptions. (or errors)
Facet counts are not correct (or total document count is not correct as they
do not match) on some searches
---
Key: SOLR-1030
URL: https://issues.apache.org/jira/browse/SOLR-1030
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Jayson Minard
There isn't much detailed evidence for this one yet, but hopefully it rings a
bell with someone who made changes in this area recently...
Since updating to the tip from our previous use of the tip from around Jan 9,
2009 we are now seeing facet counts no longer match total document count.
This is through distributed search and I have not verified that it only
happens on distributed vs. single shard search so it could be on both.
For example, on a single valued field with one facet value set as a fq
filter, combined with a text search on a simple term science, the following
is the facet count:
8,294,284
And the total document count for the same results is:
8,294,274
some debug info (not sure why the filter query is replicated more than once,
but that shouldn't be harmful):
{code}
uerystring(science)
QParser OldLuceneQParser
filter_queries[sys_content_type:(Journal Article),
sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article)]
rawquerystring(science)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1030) Facet counts are not correct (or total document count is not correct as they do not match) on some searches
[
https://issues.apache.org/jira/browse/SOLR-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675421#action_12675421
]
Jayson Minard commented on SOLR-1030:
-
I just found a bug in our database from the 27th showing this issue dates back
to r733656 as well and before. So it is an older issue.
End up with cases where facets show counts such as 264 where total results are
249.
Facet counts are not correct (or total document count is not correct as they
do not match) on some searches
---
Key: SOLR-1030
URL: https://issues.apache.org/jira/browse/SOLR-1030
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Jayson Minard
There isn't much detailed evidence for this one yet, but hopefully it rings a
bell with someone who made changes in this area recently...
Since updating to the tip from our previous use of the tip from around Jan 9,
2009 we are now seeing facet counts no longer match total document count.
This is through distributed search and I have not verified that it only
happens on distributed vs. single shard search so it could be on both.
For example, on a single valued field with one facet value set as a fq
filter, combined with a text search on a simple term science, the following
is the facet count:
8,294,284
And the total document count for the same results is:
8,294,274
some debug info (not sure why the filter query is replicated more than once,
but that shouldn't be harmful):
{code}
uerystring(science)
QParser OldLuceneQParser
filter_queries[sys_content_type:(Journal Article),
sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article)]
rawquerystring(science)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1030) Facet counts are not correct (or total document count is not correct as they do not match) on some searches
[
https://issues.apache.org/jira/browse/SOLR-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayson Minard updated SOLR-1030:
Comment: was deleted
Facet counts are not correct (or total document count is not correct as they
do not match) on some searches
---
Key: SOLR-1030
URL: https://issues.apache.org/jira/browse/SOLR-1030
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Jayson Minard
-There isn't much detailed evidence for this one yet, but hopefully it rings
a bell with someone who made changes in this area recently...-
-Since updating to the tip from our previous use of the tip from around Jan
9, 2009- (seems to be previous to r733656 as well) we are now seeing facet
counts no longer match total document count. This is through distributed
search and I have not verified that it only happens on distributed vs. single
shard search so it could be on both.
For example, on a single valued field with one facet value set as a fq
filter, combined with a text search on a simple term science, the following
is the facet count:
8,294,284
And the total document count for the same results is:
8,294,274
some debug info (not sure why the filter query is replicated more than once,
but that shouldn't be harmful):
{code}
uerystring(science)
QParser OldLuceneQParser
filter_queries[sys_content_type:(Journal Article),
sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article),
sys_content_type:(Journal Article), sys_content_type:(Journal Article)]
rawquerystring(science)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
