[jira] [Commented] (SOLR-14463) solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
[
https://issues.apache.org/jira/browse/SOLR-14463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102323#comment-17102323
]
Bernd Wahlen commented on SOLR-14463:
-
{code:java}
zk_version 3.6.1--104dcb3e3fb464b30c5186d229e00af9f332524b, built on
04/21/2020 15:01 GMT
zk_server_state leader
zk_peer_state leading - broadcast
zk_ephemerals_count 19
zk_num_alive_connections6
zk_avg_latency 0.4362
zk_min_proposal_size36
zk_outstanding_requests 0
zk_znode_count 138
zk_global_sessions 15
zk_last_client_response_size16
zk_packets_sent 38309
zk_packets_received 38264
zk_max_proposal_size1314
zk_max_client_response_size 70313
zk_synced_followers 2
zk_connection_drop_probability 0.0
zk_watch_count 25
zk_synced_non_voting_followers 0
zk_synced_observers 0
zk_min_latency 0
zk_max_file_descriptor_count1048576
zk_approximate_data_size308288
zk_open_file_descriptor_count 67
zk_last_proposal_size 36
zk_pending_syncs0
zk_leader_uptime61771446
zk_local_sessions 0
zk_uptime 61771582
zk_max_latency 2738
zk_outstanding_tls_handshake0
zk_learners 2
zk_min_client_response_size 16
zk_quorum_size 3
zk_proposal_count 121
zk_outstanding_changes_removed 124
zk_stale_requests_dropped 0
zk_large_requests_rejected 0
zk_connection_rejected 0
zk_sessionless_connections_expired 0
zk_looking_count2
zk_dead_watchers_queued 0
zk_stale_requests 0
zk_connection_drop_count1
zk_learner_proposal_received_count 71
zk_digest_mismatches_count 0
zk_dead_watchers_cleared0
zk_response_packet_cache_hits 1048
zk_bytes_received_count 701380
zk_add_dead_watcher_stall_time 0
zk_request_throttle_wait_count 0
zk_response_packet_cache_misses 47
zk_ensemble_auth_success0
zk_prep_processor_request_queued38168
zk_learner_commit_received_count71
zk_stale_replies0
zk_connection_request_count 7
zk_ensemble_auth_fail 0
zk_diff_count 2
zk_response_packet_get_children_cache_misses0
zk_connection_revalidate_count 5
zk_quit_leading_due_to_disloyal_voter 0
zk_snap_count 0
zk_unrecoverable_error_count0
zk_commit_count 121
zk_stale_sessions_expired 0
zk_response_packet_get_children_cache_hits 0
zk_sync_processor_request_queued195
zk_outstanding_changes_queued 124
zk_request_commit_queued195
zk_ensemble_auth_skip 0
zk_tls_handshake_exceeded 0
zk_revalidate_count 10
zk_avg_node_created_watch_count 0.0
zk_min_node_created_watch_count 0
zk_max_node_created_watch_count 0
zk_cnt_node_created_watch_count 0
zk_sum_node_created_watch_count 0
zk_avg_session_queues_drained 0.6205
zk_min_session_queues_drained 0
zk_max_session_queues_drained 1
zk_cnt_session_queues_drained 195
zk_sum_session_queues_drained 121
zk_avg_write_commit_proc_req_queued 0.0117
zk_min_write_commit_proc_req_queued 0
zk_max_write_commit_proc_req_queued 7
zk_cnt_write_commit_proc_req_queued 37821
zk_sum_write_commit_proc_req_queued 444
zk_avg_connection_token_deficit 0.0
zk_min_connection_token_deficit 0
zk_max_connection_token_deficit 0
zk_cnt_connection_token_deficit 7
zk_sum_connection_token_deficit 0
zk_avg_read_commit_proc_req_queued 1.0047
zk_min_read_commit_proc_req_queued 0
zk_max_read_commit_proc_req_queued 5
zk_cnt_read_commit_proc_req_queued 37821
zk_sum_read_commit_proc_req_queued 37998
zk_avg_node_deleted_watch_count 0.0
zk_min_node_deleted_watch_count 0
zk_max_node_deleted_watch_count 0
zk_cnt_node_deleted_watch_count 0
zk_sum_node_deleted_watch_count 0
zk_avg_startup_txns_load_time 19.0
zk_min_startup_txns_load_time 19
zk_max_startup_txns_load_time 19
zk_cnt_startup_txns_load_time 1
zk_sum_startup_txns_load_time 19
zk_avg_sync_processor_queue_size0.132
zk_min_sync_processor_queue_size0
zk_max_sync_processor_queue_size3
zk_cnt_sync_processor_queue_size197
zk_sum_sync_processor_queue_size26
zk_avg_follower_sync_time 33.0
zk_min_follower_sync_time 33
zk_max_follower_sync_time 33
zk_cnt_follower_sync_time 1
zk_sum_follower_sync_time 33
zk_avg_prep_processor_queue_size0.0103
zk_min_prep_processor_queue_size0
zk_max_prep_processor_queue_size4
zk_cnt_prep_processor_queue_size38169
zk_sum_prep_processor_queue_size393
zk_avg_fsynctime0.052
zk_min_fsynctime0
zk_max_fsynctime4
zk_cnt_fsynctime173
zk_sum_fsynctime9
zk_avg_reads_issued_from_session_queue 0.0308
zk_min_reads_issued_from_session_queue 0
zk_max_reads_issued_from_session_queue 2
zk_cnt_reads_issued_from_session_queue 195
zk_sum_reads_issued_from_session_queue 6
zk_avg_snapshottime 6.0
zk_min_snapshottime 6
zk_max_snapshottime 6
zk_cnt_snapshottime 1
zk_sum_snap
[jira] [Comment Edited] (SOLR-14463) solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
[
https://issues.apache.org/jira/browse/SOLR-14463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102323#comment-17102323
]
Bernd Wahlen edited comment on SOLR-14463 at 5/8/20, 7:14 AM:
--
You are right zk_followers is missing, but cluster is working @see
zk_synced_followers
{code:java}
zk_version 3.6.1--104dcb3e3fb464b30c5186d229e00af9f332524b, built on
04/21/2020 15:01 GMT
zk_server_state leader
zk_peer_state leading - broadcast
zk_ephemerals_count 19
zk_num_alive_connections6
zk_avg_latency 0.4362
zk_min_proposal_size36
zk_outstanding_requests 0
zk_znode_count 138
zk_global_sessions 15
zk_last_client_response_size16
zk_packets_sent 38309
zk_packets_received 38264
zk_max_proposal_size1314
zk_max_client_response_size 70313
zk_synced_followers 2
zk_connection_drop_probability 0.0
zk_watch_count 25
zk_synced_non_voting_followers 0
zk_synced_observers 0
zk_min_latency 0
zk_max_file_descriptor_count1048576
zk_approximate_data_size308288
zk_open_file_descriptor_count 67
zk_last_proposal_size 36
zk_pending_syncs0
zk_leader_uptime61771446
zk_local_sessions 0
zk_uptime 61771582
zk_max_latency 2738
zk_outstanding_tls_handshake0
zk_learners 2
zk_min_client_response_size 16
zk_quorum_size 3
zk_proposal_count 121
zk_outstanding_changes_removed 124
zk_stale_requests_dropped 0
zk_large_requests_rejected 0
zk_connection_rejected 0
zk_sessionless_connections_expired 0
zk_looking_count2
zk_dead_watchers_queued 0
zk_stale_requests 0
zk_connection_drop_count1
zk_learner_proposal_received_count 71
zk_digest_mismatches_count 0
zk_dead_watchers_cleared0
zk_response_packet_cache_hits 1048
zk_bytes_received_count 701380
zk_add_dead_watcher_stall_time 0
zk_request_throttle_wait_count 0
zk_response_packet_cache_misses 47
zk_ensemble_auth_success0
zk_prep_processor_request_queued38168
zk_learner_commit_received_count71
zk_stale_replies0
zk_connection_request_count 7
zk_ensemble_auth_fail 0
zk_diff_count 2
zk_response_packet_get_children_cache_misses0
zk_connection_revalidate_count 5
zk_quit_leading_due_to_disloyal_voter 0
zk_snap_count 0
zk_unrecoverable_error_count0
zk_commit_count 121
zk_stale_sessions_expired 0
zk_response_packet_get_children_cache_hits 0
zk_sync_processor_request_queued195
zk_outstanding_changes_queued 124
zk_request_commit_queued195
zk_ensemble_auth_skip 0
zk_tls_handshake_exceeded 0
zk_revalidate_count 10
zk_avg_node_created_watch_count 0.0
zk_min_node_created_watch_count 0
zk_max_node_created_watch_count 0
zk_cnt_node_created_watch_count 0
zk_sum_node_created_watch_count 0
zk_avg_session_queues_drained 0.6205
zk_min_session_queues_drained 0
zk_max_session_queues_drained 1
zk_cnt_session_queues_drained 195
zk_sum_session_queues_drained 121
zk_avg_write_commit_proc_req_queued 0.0117
zk_min_write_commit_proc_req_queued 0
zk_max_write_commit_proc_req_queued 7
zk_cnt_write_commit_proc_req_queued 37821
zk_sum_write_commit_proc_req_queued 444
zk_avg_connection_token_deficit 0.0
zk_min_connection_token_deficit 0
zk_max_connection_token_deficit 0
zk_cnt_connection_token_deficit 7
zk_sum_connection_token_deficit 0
zk_avg_read_commit_proc_req_queued 1.0047
zk_min_read_commit_proc_req_queued 0
zk_max_read_commit_proc_req_queued 5
zk_cnt_read_commit_proc_req_queued 37821
zk_sum_read_commit_proc_req_queued 37998
zk_avg_node_deleted_watch_count 0.0
zk_min_node_deleted_watch_count 0
zk_max_node_deleted_watch_count 0
zk_cnt_node_deleted_watch_count 0
zk_sum_node_deleted_watch_count 0
zk_avg_startup_txns_load_time 19.0
zk_min_startup_txns_load_time 19
zk_max_startup_txns_load_time 19
zk_cnt_startup_txns_load_time 1
zk_sum_startup_txns_load_time 19
zk_avg_sync_processor_queue_size0.132
zk_min_sync_processor_queue_size0
zk_max_sync_processor_queue_size3
zk_cnt_sync_processor_queue_size197
zk_sum_sync_processor_queue_size26
zk_avg_follower_sync_time 33.0
zk_min_follower_sync_time 33
zk_max_follower_sync_time 33
zk_cnt_follower_sync_time 1
zk_sum_follower_sync_time 33
zk_avg_prep_processor_queue_size0.0103
zk_min_prep_processor_queue_size0
zk_max_prep_processor_queue_size4
zk_cnt_prep_processor_queue_size38169
zk_sum_prep_processor_queue_size393
zk_avg_fsynctime0.052
zk_min_fsynctime0
zk_max_fsynctime4
zk_cnt_fsynctime173
zk_sum_fsynctime9
zk_avg_reads_issued_from_session_queue 0.0308
zk_min_reads_issued_from_session_queue 0
zk_max_reads_issued_from_session_queue 2
zk_cnt_reads_issued_from_session_queue 195
zk_sum_reads_issued_f
[jira] [Comment Edited] (SOLR-14463) solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
[
https://issues.apache.org/jira/browse/SOLR-14463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102323#comment-17102323
]
Bernd Wahlen edited comment on SOLR-14463 at 5/8/20, 7:21 AM:
--
You are right zk_followers is missing, but cluster is working @see
zk_synced_followers.
So what do you think? Workaroud it in solr, open a zookeeper bug (zk_followers
is still in the documentation of 3.6.1) or both?
{code:java}
zk_version 3.6.1--104dcb3e3fb464b30c5186d229e00af9f332524b, built on
04/21/2020 15:01 GMT
zk_server_state leader
zk_peer_state leading - broadcast
zk_ephemerals_count 19
zk_num_alive_connections6
zk_avg_latency 0.4362
zk_min_proposal_size36
zk_outstanding_requests 0
zk_znode_count 138
zk_global_sessions 15
zk_last_client_response_size16
zk_packets_sent 38309
zk_packets_received 38264
zk_max_proposal_size1314
zk_max_client_response_size 70313
zk_synced_followers 2
zk_connection_drop_probability 0.0
zk_watch_count 25
zk_synced_non_voting_followers 0
zk_synced_observers 0
zk_min_latency 0
zk_max_file_descriptor_count1048576
zk_approximate_data_size308288
zk_open_file_descriptor_count 67
zk_last_proposal_size 36
zk_pending_syncs0
zk_leader_uptime61771446
zk_local_sessions 0
zk_uptime 61771582
zk_max_latency 2738
zk_outstanding_tls_handshake0
zk_learners 2
zk_min_client_response_size 16
zk_quorum_size 3
zk_proposal_count 121
zk_outstanding_changes_removed 124
zk_stale_requests_dropped 0
zk_large_requests_rejected 0
zk_connection_rejected 0
zk_sessionless_connections_expired 0
zk_looking_count2
zk_dead_watchers_queued 0
zk_stale_requests 0
zk_connection_drop_count1
zk_learner_proposal_received_count 71
zk_digest_mismatches_count 0
zk_dead_watchers_cleared0
zk_response_packet_cache_hits 1048
zk_bytes_received_count 701380
zk_add_dead_watcher_stall_time 0
zk_request_throttle_wait_count 0
zk_response_packet_cache_misses 47
zk_ensemble_auth_success0
zk_prep_processor_request_queued38168
zk_learner_commit_received_count71
zk_stale_replies0
zk_connection_request_count 7
zk_ensemble_auth_fail 0
zk_diff_count 2
zk_response_packet_get_children_cache_misses0
zk_connection_revalidate_count 5
zk_quit_leading_due_to_disloyal_voter 0
zk_snap_count 0
zk_unrecoverable_error_count0
zk_commit_count 121
zk_stale_sessions_expired 0
zk_response_packet_get_children_cache_hits 0
zk_sync_processor_request_queued195
zk_outstanding_changes_queued 124
zk_request_commit_queued195
zk_ensemble_auth_skip 0
zk_tls_handshake_exceeded 0
zk_revalidate_count 10
zk_avg_node_created_watch_count 0.0
zk_min_node_created_watch_count 0
zk_max_node_created_watch_count 0
zk_cnt_node_created_watch_count 0
zk_sum_node_created_watch_count 0
zk_avg_session_queues_drained 0.6205
zk_min_session_queues_drained 0
zk_max_session_queues_drained 1
zk_cnt_session_queues_drained 195
zk_sum_session_queues_drained 121
zk_avg_write_commit_proc_req_queued 0.0117
zk_min_write_commit_proc_req_queued 0
zk_max_write_commit_proc_req_queued 7
zk_cnt_write_commit_proc_req_queued 37821
zk_sum_write_commit_proc_req_queued 444
zk_avg_connection_token_deficit 0.0
zk_min_connection_token_deficit 0
zk_max_connection_token_deficit 0
zk_cnt_connection_token_deficit 7
zk_sum_connection_token_deficit 0
zk_avg_read_commit_proc_req_queued 1.0047
zk_min_read_commit_proc_req_queued 0
zk_max_read_commit_proc_req_queued 5
zk_cnt_read_commit_proc_req_queued 37821
zk_sum_read_commit_proc_req_queued 37998
zk_avg_node_deleted_watch_count 0.0
zk_min_node_deleted_watch_count 0
zk_max_node_deleted_watch_count 0
zk_cnt_node_deleted_watch_count 0
zk_sum_node_deleted_watch_count 0
zk_avg_startup_txns_load_time 19.0
zk_min_startup_txns_load_time 19
zk_max_startup_txns_load_time 19
zk_cnt_startup_txns_load_time 1
zk_sum_startup_txns_load_time 19
zk_avg_sync_processor_queue_size0.132
zk_min_sync_processor_queue_size0
zk_max_sync_processor_queue_size3
zk_cnt_sync_processor_queue_size197
zk_sum_sync_processor_queue_size26
zk_avg_follower_sync_time 33.0
zk_min_follower_sync_time 33
zk_max_follower_sync_time 33
zk_cnt_follower_sync_time 1
zk_sum_follower_sync_time 33
zk_avg_prep_processor_queue_size0.0103
zk_min_prep_processor_queue_size0
zk_max_prep_processor_queue_size4
zk_cnt_prep_processor_queue_size38169
zk_sum_prep_processor_queue_size393
zk_avg_fsynctime0.052
zk_min_fsynctime0
zk_max_fsynctime4
zk_cnt_fsynctime173
zk_sum_fsynctime9
zk_avg_reads_issued_from_session_queue 0.0308
zk_min_reads_issued
[jira] [Updated] (LUCENE-9328) SortingGroupHead to reuse DocValues
[ https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9328: - Attachment: LUCENE-9328.patch Status: Patch Available (was: Patch Available) > SortingGroupHead to reuse DocValues > --- > > Key: LUCENE-9328 > URL: https://issues.apache.org/jira/browse/LUCENE-9328 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/grouping >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Minor > Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch > > Time Spent: 1h 50m > Remaining Estimate: 0h > > That's why > https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14463) solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
[
https://issues.apache.org/jira/browse/SOLR-14463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102400#comment-17102400
]
Jan Høydahl commented on SOLR-14463:
I think create a patch for Solr to be tolerant for null values and don't crash,
and when counting followers, then count the sum of {{zk_followers}} and
{{zk_synced_followers}}. Do you want to attempt a PR?
> solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
> ---
>
> Key: SOLR-14463
> URL: https://issues.apache.org/jira/browse/SOLR-14463
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5.1
>Reporter: Bernd Wahlen
>Assignee: Jan Høydahl
>Priority: Major
>
> When i select in solr 8.5.1 webinterface: Cloud - ZK Status i got
> For input string: "null"
> This happens after upgrading the leader to zookeeper 3.6.1 (upgrading the
> followers before was not a problem). From my view configuration is running,
> just the status web page doesn't.
> I remember that there was similar problem before with solr/zk version
> incompatibilities. From zookeeper documentation 3.6.1 should be fully
> compatible with 3.5 clients.
> Annoyingly there is no official zk 3.6.1 docker container available, but i
> think it is easy to reproduce.
> and from solr.log file:
> {code:java}
> 2020-05-07 15:58:33.194 ERROR (qtp1940055334-231) [ ]
> o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string:
> "null"
> at
> java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.base/java.lang.Integer.parseInt(Integer.java:652)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:842)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:808)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:559)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:420)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:352)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1607)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1297)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1577)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1212)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.
[jira] [Updated] (SOLR-14411) Fix regression from SOLR-14359 (Admin UI 'Select an Option')
[ https://issues.apache.org/jira/browse/SOLR-14411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14411: --- Fix Version/s: 8.5.2 > Fix regression from SOLR-14359 (Admin UI 'Select an Option') > > > Key: SOLR-14411 > URL: https://issues.apache.org/jira/browse/SOLR-14411 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.6, 8.5.2 > > > SOLR-14359 attempted to fix a bug in the Admin UI in v8.5.1 but the fix had a > bug. > The bug is already fixed using SOLR-14359 in the commit message, but I'm > creating a new JIRA number for clarity in CHANGES.txt. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14411) Fix regression from SOLR-14359 (Admin UI 'Select an Option')
[ https://issues.apache.org/jira/browse/SOLR-14411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102465#comment-17102465 ] Jan Høydahl commented on SOLR-14411: I'm backporting this to the upcoming 8.5.2 > Fix regression from SOLR-14359 (Admin UI 'Select an Option') > > > Key: SOLR-14411 > URL: https://issues.apache.org/jira/browse/SOLR-14411 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.6, 8.5.2 > > > SOLR-14359 attempted to fix a bug in the Admin UI in v8.5.1 but the fix had a > bug. > The bug is already fixed using SOLR-14359 in the commit message, but I'm > creating a new JIRA number for clarity in CHANGES.txt. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14411) Fix regression from SOLR-14359 (Admin UI 'Select an Option')
[ https://issues.apache.org/jira/browse/SOLR-14411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102495#comment-17102495 ] ASF subversion and git services commented on SOLR-14411: Commit 5acbf143d99476e59144637ba50da7794cc51d06 in lucene-solr's branch refs/heads/branch_8_5 from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5acbf14 ] SOLR-14411: Fix Admin UI collection/core drop-downs placeholder text. Completes work started in SOLR-14359 > Fix regression from SOLR-14359 (Admin UI 'Select an Option') > > > Key: SOLR-14411 > URL: https://issues.apache.org/jira/browse/SOLR-14411 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.6, 8.5.2 > > > SOLR-14359 attempted to fix a bug in the Admin UI in v8.5.1 but the fix had a > bug. > The bug is already fixed using SOLR-14359 in the commit message, but I'm > creating a new JIRA number for clarity in CHANGES.txt. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14359) Admin UI has "Select an option" for collections and cores drop-downs.
[ https://issues.apache.org/jira/browse/SOLR-14359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102496#comment-17102496 ] ASF subversion and git services commented on SOLR-14359: Commit 5acbf143d99476e59144637ba50da7794cc51d06 in lucene-solr's branch refs/heads/branch_8_5 from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5acbf14 ] SOLR-14411: Fix Admin UI collection/core drop-downs placeholder text. Completes work started in SOLR-14359 > Admin UI has "Select an option" for collections and cores drop-downs. > - > > Key: SOLR-14359 > URL: https://issues.apache.org/jira/browse/SOLR-14359 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.5 >Reporter: Erick Erickson >Assignee: Jan Høydahl >Priority: Minor > Fix For: 8.5.1 > > Attachments: SOLR-14359-fix.patch, Screen Shot 2020-03-23 at 10.23.43 > AM.png > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy opened a new pull request #1499: SOLR-14463: Solr Admin ZkStatus page now works with ZK 3.6
janhoy opened a new pull request #1499: URL: https://github.com/apache/lucene-solr/pull/1499 See https://issues.apache.org/jira/browse/SOLR-14463 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14463) solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
[
https://issues.apache.org/jira/browse/SOLR-14463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102522#comment-17102522
]
Jan Høydahl commented on SOLR-14463:
See https://github.com/apache/lucene-solr/pull/1499 for a first PR
> solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
> ---
>
> Key: SOLR-14463
> URL: https://issues.apache.org/jira/browse/SOLR-14463
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5.1
>Reporter: Bernd Wahlen
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When i select in solr 8.5.1 webinterface: Cloud - ZK Status i got
> For input string: "null"
> This happens after upgrading the leader to zookeeper 3.6.1 (upgrading the
> followers before was not a problem). From my view configuration is running,
> just the status web page doesn't.
> I remember that there was similar problem before with solr/zk version
> incompatibilities. From zookeeper documentation 3.6.1 should be fully
> compatible with 3.5 clients.
> Annoyingly there is no official zk 3.6.1 docker container available, but i
> think it is easy to reproduce.
> and from solr.log file:
> {code:java}
> 2020-05-07 15:58:33.194 ERROR (qtp1940055334-231) [ ]
> o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string:
> "null"
> at
> java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.base/java.lang.Integer.parseInt(Integer.java:652)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:842)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:808)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:559)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:420)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:352)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1607)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1297)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1577)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1212)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.
[jira] [Commented] (SOLR-14463) solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
[
https://issues.apache.org/jira/browse/SOLR-14463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102595#comment-17102595
]
Bernd Wahlen commented on SOLR-14463:
-
Thanks for the quick patch, but when i check the output of 3.5.7 i got:
{code:java}
zk_version 3.5.7-f0fdd52973d373ffd9c86b81d99842dc2c7f660e, built on
02/10/2020 11:30 GMT
zk_avg_latency 0
zk_max_latency 13
zk_min_latency 0
zk_packets_received 324
zk_packets_sent 323
zk_num_alive_connections2
zk_outstanding_requests 0
zk_server_state leader
zk_znode_count 122
zk_watch_count 5
zk_ephemerals_count 9
zk_approximate_data_size331461
zk_open_file_descriptor_count 52
zk_max_file_descriptor_count1048576
zk_followers2
zk_synced_followers 2
zk_pending_syncs0
zk_last_proposal_size 92
zk_max_proposal_size705
zk_min_proposal_size32
{code}
So i think for 3.6.x your patch is correct, but for 3.5.x it will return 4 (2
zk_followers + 2 zk_synced_followers) instead of 2 in a typical cluster of 3 zk
instances.
> solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
> ---
>
> Key: SOLR-14463
> URL: https://issues.apache.org/jira/browse/SOLR-14463
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5.1
>Reporter: Bernd Wahlen
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When i select in solr 8.5.1 webinterface: Cloud - ZK Status i got
> For input string: "null"
> This happens after upgrading the leader to zookeeper 3.6.1 (upgrading the
> followers before was not a problem). From my view configuration is running,
> just the status web page doesn't.
> I remember that there was similar problem before with solr/zk version
> incompatibilities. From zookeeper documentation 3.6.1 should be fully
> compatible with 3.5 clients.
> Annoyingly there is no official zk 3.6.1 docker container available, but i
> think it is easy to reproduce.
> and from solr.log file:
> {code:java}
> 2020-05-07 15:58:33.194 ERROR (qtp1940055334-231) [ ]
> o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string:
> "null"
> at
> java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.base/java.lang.Integer.parseInt(Integer.java:652)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:842)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:808)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:559)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:420)
> at
> org.apache.solr.servlet.SolrDispatchF
[GitHub] [lucene-solr] gus-asf commented on pull request #967: SOLR-13857 - fix QueryParser.jj and FastCharStream such that generated
gus-asf commented on pull request #967: URL: https://github.com/apache/lucene-solr/pull/967#issuecomment-625823935 hmm, apparently didn't get back to this merge is horrific. Will re-make if still needed This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13857) QueryParser.jj produces code that will not compile
[ https://issues.apache.org/jira/browse/SOLR-13857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck resolved SOLR-13857. - Resolution: Won't Fix The gradle build appears to have this under control. > QueryParser.jj produces code that will not compile > -- > > Key: SOLR-13857 > URL: https://issues.apache.org/jira/browse/SOLR-13857 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > There are 2 problems that have crept into the parser generation system. > # SOLR-8764 removed deprecated methods that are part of a generated > interface (and the implementation thereof). It's kind of stinky that Javacc > is generating an interface that includes deprecated methods, but deleting > them from the generated class means that re-generation causes compiler > errors, so this should probably be reverted. > # SOLR-11662 changed the signature of > org.apache.solr.parser.QueryParser#newFieldQuery to add a parameter, but did > not update the corresponding portion of the QueryParser.jj file, and so the > method signature reverts upon regeneration, causing compile errors. > # There are a few places where string concatenation was turned to .append() > The pull request to be attached soon fixes these two issues such that running > ant javacc-QueryParser will once again produce code that compiles. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9098) Report problematic term value when fuzzy query is too complex
[ https://issues.apache.org/jira/browse/LUCENE-9098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated LUCENE-9098: -- Fix Version/s: 8.5 Updating fix versions - this was also back ported as part of LUCENE-9068 > Report problematic term value when fuzzy query is too complex > - > > Key: LUCENE-9098 > URL: https://issues.apache.org/jira/browse/LUCENE-9098 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Minor > Fix For: master (9.0), 8.5 > > Time Spent: 50m > Remaining Estimate: 0h > > This is the lucene compliment to SOLR-13190, when fuzzy query gets a term > that expands to too many states, we throw an exception but don't provide > insight on the problematic term. We should improve the error reporting. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14465) Reproducing seed in FuzzySearchTest
[ https://issues.apache.org/jira/browse/SOLR-14465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102642#comment-17102642 ] ASF subversion and git services commented on SOLR-14465: Commit b5793f465b0327e11f0896c7eec8e522fdd2ed7d in lucene-solr's branch refs/heads/branch_8x from Mike Drob [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b5793f4 ] SOLR-14465: Solr query handling code catches FuzzyTermsException This reverts commit 7ea7ed72aca556f957a5de55911c852124db8715. > Reproducing seed in FuzzySearchTest > --- > > Key: SOLR-14465 > URL: https://issues.apache.org/jira/browse/SOLR-14465 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Affects Versions: master (9.0) >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > > reproduce with: ant test -Dtestcase=FuzzySearchTest > -Dtests.method=testTooComplex -Dtests.seed=B6A1F20B2D413B4 > -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true > -Dtests.locale=yue-Hant-HK -Dtests.timezone=America/Dawson > -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > > [~romseygeek] [~mdrob] My guess is that changes in LUCENE-9350/LUCENE-9068 > changed the exception returned, but haven't looked very closely. > [junit4] FAILURE 3.01s | FuzzySearchTest.testTooComplex <<< > [junit4] > Throwable #1: junit.framework.AssertionFailedError: Unexpected > exception type, expected RemoteSolrException but got > org.apache.solr.client.solrj.SolrServerException: No live SolrServers > available to handle this request:[http://127.0.0.1:51202/solr/c1] > [junit4] > at > __randomizedtesting.SeedInfo.seed([B6A1F20B2D413B4:DDC85504AD0720FE]:0) > [junit4] > at > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2751) > [junit4] > at > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2739) > [junit4] > at > org.apache.solr.search.FuzzySearchTest.testTooComplex(FuzzySearchTest.java:64) > [junit4] > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [junit4] > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [junit4] > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [junit4] > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > [junit4] > at java.base/java.lang.Thread.run(Thread.java:834) > [junit4] > Caused by: org.apache.solr.client.solrj.SolrServerException: No > live SolrServers available to handle this > request:[http://127.0.0.1:51202/solr/c1] > [junit4] > at > org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:345) > [junit4] > at > org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1147) > [junit4] > at > org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:910) > [junit4] > at > org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:842) > [junit4] > at > org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) > [junit4] > at > org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1004) > [junit4] > at > org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1019) > [junit4] > at > org.apache.solr.search.FuzzySearchTest.lambda$testTooComplex$0(FuzzySearchTest.java:64) > [junit4] > at > org.apache.lucene.util.LuceneTestCase._expectThrows(LuceneTestCase.java:2869) > [junit4] > at > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2744) > [junit4] > ... 41 more > [junit4] > Caused by: > org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException: > Error from server at http://127.0.0.1:51202/solr/c1: Term too complex: > headquarters(在日米海軍横須賀基地司令部庁舎/旧横須賀鎮守府会議所・横須賀海軍艦船部) > [junit4] > at > org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:665) > [junit4] > at > org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:265) > [junit4] > at org.apache.solr.client.solrj.impl.HttpSolrClient.request( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13190) Fuzzy search treated as server error instead of client error when terms are too complex
[
https://issues.apache.org/jira/browse/SOLR-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102641#comment-17102641
]
ASF subversion and git services commented on SOLR-13190:
Commit bad85f7c5aceb048e23fa343357dd807954d9ca7 in lucene-solr's branch
refs/heads/branch_8x from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bad85f7 ]
SOLR-13190 Backport unit test
> Fuzzy search treated as server error instead of client error when terms are
> too complex
> ---
>
> Key: SOLR-13190
> URL: https://issues.apache.org/jira/browse/SOLR-13190
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 5.5, 7.7, 8.0
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We've seen a fuzzy search end up breaking the automaton and getting reported
> as a server error. This usage should be improved by
> 1) reporting as a client error, because it's similar to something like too
> many boolean clauses queries in how an operator should deal with it
> 2) report what field is causing the error, since that currently must be
> deduced from adjacent query logs and can be difficult if there are multiple
> terms in the search
> This trigger was added to defend against adversarial regex but somehow hits
> fuzzy terms as well, I don't understand enough about the automaton mechanisms
> to really know how to approach a fix there, but improving the operability is
> a good first step.
> relevant stack trace:
> {noformat}
> org.apache.lucene.util.automaton.TooComplexToDeterminizeException:
> Determinizing automaton with 13632 states and 21348 transitions would result
> in more than 1 states.
> at
> org.apache.lucene.util.automaton.Operations.determinize(Operations.java:746)
> at
> org.apache.lucene.util.automaton.RunAutomaton.(RunAutomaton.java:69)
> at
> org.apache.lucene.util.automaton.ByteRunAutomaton.(ByteRunAutomaton.java:32)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:247)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:133)
> at
> org.apache.lucene.search.FuzzyTermsEnum.(FuzzyTermsEnum.java:143)
> at org.apache.lucene.search.FuzzyQuery.getTermsEnum(FuzzyQuery.java:154)
> at
> org.apache.lucene.search.MultiTermQuery$RewriteMethod.getTermsEnum(MultiTermQuery.java:78)
> at
> org.apache.lucene.search.TermCollectingRewrite.collectTerms(TermCollectingRewrite.java:58)
> at
> org.apache.lucene.search.TopTermsRewrite.rewrite(TopTermsRewrite.java:67)
> at
> org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:310)
> at
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:442)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1435)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:374)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13857) QueryParser.jj produces code that will not compile
[ https://issues.apache.org/jira/browse/SOLR-13857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102674#comment-17102674 ] Erick Erickson commented on SOLR-13857: --- Good catch, this has been rendered obsolete by the Gradle build. I spent quite a bit of time when porting the regenerate task to Gradle automating the hand-edits that needed to be done, they're all part of the regenerate task, no hand-edits needed. And you're correct, I didn't go back and re-do the ant versions so this is gradle-only. > QueryParser.jj produces code that will not compile > -- > > Key: SOLR-13857 > URL: https://issues.apache.org/jira/browse/SOLR-13857 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > There are 2 problems that have crept into the parser generation system. > # SOLR-8764 removed deprecated methods that are part of a generated > interface (and the implementation thereof). It's kind of stinky that Javacc > is generating an interface that includes deprecated methods, but deleting > them from the generated class means that re-generation causes compiler > errors, so this should probably be reverted. > # SOLR-11662 changed the signature of > org.apache.solr.parser.QueryParser#newFieldQuery to add a parameter, but did > not update the corresponding portion of the QueryParser.jj file, and so the > method signature reverts upon regeneration, causing compile errors. > # There are a few places where string concatenation was turned to .append() > The pull request to be attached soon fixes these two issues such that running > ant javacc-QueryParser will once again produce code that compiles. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob opened a new pull request #1500: Backport LUCENE-9350 to branch_8_5
madrob opened a new pull request #1500: URL: https://github.com/apache/lucene-solr/pull/1500 It may be worthwhile to review this by individual commits instead of all at once. I do not intend to squash these when committing. I'm most concerned about whether the changes in commit 3363df7 are sufficient - they are enough for API and compilation, but it's not clear if I needed to update some implementations of QueryVisitor to tie all of this together. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13289) Support for BlockMax WAND
[
https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102722#comment-17102722
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-13289:
--
OK, I updated the response to include a boolean {{hitCountExact}}:
json:
{code:javascript}
"response": {
"numFound": 4,
"start": 0,
"hitCountExact": false,
"docs": Array[2]
...
{code}
XML:
{code:xml}
...
{code}
Java:
{code:java}
public Boolean getHitCountExact() {
return hitCountExact;
}
{code}
> Support for BlockMax WAND
> -
>
> Key: SOLR-13289
> URL: https://issues.apache.org/jira/browse/SOLR-13289
> Project: Solr
> Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-13289.patch, SOLR-13289.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to
> expose this via Solr. When enabled, the numFound returned will not be exact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1456: SOLR-13289: Support for BlockMax WAND
tflobbe commented on a change in pull request #1456: URL: https://github.com/apache/lucene-solr/pull/1456#discussion_r422255574 ## File path: solr/core/src/java/org/apache/solr/search/QueryResultKey.java ## @@ -65,6 +70,7 @@ public QueryResultKey(Query query, List filters, Sort sort, int nc_flags) h = h*29 + sf.hashCode(); ramSfields += BASE_SF_RAM_BYTES_USED + RamUsageEstimator.sizeOfObject(sf.getField()); } +h = h*31 + minExactHits; Review comment: Added a test This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13289) Support for BlockMax WAND
[
https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102755#comment-17102755
]
Ishan Chattopadhyaya commented on SOLR-13289:
-
Instead of {{hitCountExact=false}}, I'd rather prefer {{numFoundExact=false}}
or {{numFoundExactness=false}}
> Support for BlockMax WAND
> -
>
> Key: SOLR-13289
> URL: https://issues.apache.org/jira/browse/SOLR-13289
> Project: Solr
> Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-13289.patch, SOLR-13289.patch
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to
> expose this via Solr. When enabled, the numFound returned will not be exact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14466) Upgrade log4j2 to latest release (2.13.2)
[ https://issues.apache.org/jira/browse/SOLR-14466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102788#comment-17102788 ] ASF subversion and git services commented on SOLR-14466: Commit 1e24086ea6e807ea851dc86cdc90db977b988d7b in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1e24086 ] SOLR-14466: Upgrade log4j2 to latest release (2.13.2) > Upgrade log4j2 to latest release (2.13.2) > - > > Key: SOLR-14466 > URL: https://issues.apache.org/jira/browse/SOLR-14466 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: logging >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > > Before diving back into the occasional failures because, apparently, async > logging isn't flushing all the buffered log messages as expected, I think > it's worth upgrading log4j2. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14466) Upgrade log4j2 to latest release (2.13.2)
[ https://issues.apache.org/jira/browse/SOLR-14466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102787#comment-17102787 ] ASF subversion and git services commented on SOLR-14466: Commit 4a76a59d69728ac953332217b14b763a11c82aaf in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4a76a59 ] SOLR-14466: Upgrade log4j2 to latest release (2.13.2) > Upgrade log4j2 to latest release (2.13.2) > - > > Key: SOLR-14466 > URL: https://issues.apache.org/jira/browse/SOLR-14466 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: logging >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > > Before diving back into the occasional failures because, apparently, async > logging isn't flushing all the buffered log messages as expected, I think > it's worth upgrading log4j2. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14466) Upgrade log4j2 to latest release (2.13.2)
[ https://issues.apache.org/jira/browse/SOLR-14466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14466. --- Fix Version/s: 8.6 Resolution: Fixed > Upgrade log4j2 to latest release (2.13.2) > - > > Key: SOLR-14466 > URL: https://issues.apache.org/jira/browse/SOLR-14466 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: logging >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.6 > > > Before diving back into the occasional failures because, apparently, async > logging isn't flushing all the buffered log messages as expected, I think > it's worth upgrading log4j2. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] romseygeek commented on pull request #1500: Backport LUCENE-9350 to branch_8_5
romseygeek commented on pull request #1500: URL: https://github.com/apache/lucene-solr/pull/1500#issuecomment-625942131 I don't think we should backport the changes to QueryVisitor, we shouldn't be breaking APIs in a bugfix release even if it is experimental. Can we change it to build the automaton directly in FuzzyQuery.visit()? It's not ideal, but it's the status quo ante This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13289) Support for BlockMax WAND
[ https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102867#comment-17102867 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-13289: -- numFoundExact sounds better to me too. I updated. I plan to merge the current PR to master and 8.x. I'll do another PR for docs. > Support for BlockMax WAND > - > > Key: SOLR-13289 > URL: https://issues.apache.org/jira/browse/SOLR-13289 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: SOLR-13289.patch, SOLR-13289.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to > expose this via Solr. When enabled, the numFound returned will not be exact. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on pull request #1500: Backport LUCENE-9350 to branch_8_5
madrob commented on pull request #1500: URL: https://github.com/apache/lucene-solr/pull/1500#issuecomment-626003039 > Can we change it to build the automaton directly in FuzzyQuery.visit() Sure, I dropped the QueryVisitor changes and we do this now. I think the changes to use a Supplier in FuzzyTermsEnum are still ok? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14463) solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
[
https://issues.apache.org/jira/browse/SOLR-14463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102918#comment-17102918
]
Jan Høydahl commented on SOLR-14463:
Ah, I thought about whether synced_followers is a subset of followers. I have
pushed a fix taking max of the two numbers.
I agree it might be a bug that zk_followers is not returned in 3.6. I asked a
question on the ZK slack channel.
> solr admin ui: zkstatus: For input string: "null" with zk 3.6.x
> ---
>
> Key: SOLR-14463
> URL: https://issues.apache.org/jira/browse/SOLR-14463
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5.1
>Reporter: Bernd Wahlen
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When i select in solr 8.5.1 webinterface: Cloud - ZK Status i got
> For input string: "null"
> This happens after upgrading the leader to zookeeper 3.6.1 (upgrading the
> followers before was not a problem). From my view configuration is running,
> just the status web page doesn't.
> I remember that there was similar problem before with solr/zk version
> incompatibilities. From zookeeper documentation 3.6.1 should be fully
> compatible with 3.5 clients.
> Annoyingly there is no official zk 3.6.1 docker container available, but i
> think it is easy to reproduce.
> and from solr.log file:
> {code:java}
> 2020-05-07 15:58:33.194 ERROR (qtp1940055334-231) [ ]
> o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string:
> "null"
> at
> java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.base/java.lang.Integer.parseInt(Integer.java:652)
> at java.base/java.lang.Integer.parseInt(Integer.java:770)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116)
> at
> org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:842)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:808)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:559)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:420)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:352)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1607)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1297)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1577)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1212)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server
[jira] [Updated] (SOLR-13590) Allow zplot to plot 2D clusters in Apache Zeppelin
[ https://issues.apache.org/jira/browse/SOLR-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-13590: - Component/s: streaming expressions > Allow zplot to plot 2D clusters in Apache Zeppelin > -- > > Key: SOLR-13590 > URL: https://issues.apache.org/jira/browse/SOLR-13590 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Priority: Major > > The ticket will allow the *zplot* function to plot 2D clusters using Apache > Zeppelin. This will be designed to work with the output of the existing > *kmeans* clustering function and *dbscan* (SOLR-10786) clustering when it's > added. > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13289) Support for BlockMax WAND
[ https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102951#comment-17102951 ] ASF subversion and git services commented on SOLR-13289: Commit d9f9d6dd47c06f5fe092d43d6bf0c77c5ff2019f in lucene-solr's branch refs/heads/master from Tomas Eduardo Fernandez Lobbe [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d9f9d6d ] SOLR-13289: Add Support for BlockMax WAND (#1456) Add support for BlockMax WAND via a minExactHits parameter. Hits will be counted accurately at least until this value, and above that, the count will be an approximation. In distributed search requests, the count will be per shard, so potentially the count will be accurately counted until numShards * minExactHits. The response will include the value numFoundExact which can be true (The value in numFound is exact) or false (the value in numFound is an approximation). > Support for BlockMax WAND > - > > Key: SOLR-13289 > URL: https://issues.apache.org/jira/browse/SOLR-13289 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: SOLR-13289.patch, SOLR-13289.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to > expose this via Solr. When enabled, the numFound returned will not be exact. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9328) SortingGroupHead to reuse DocValues
[
https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102955#comment-17102955
]
Lucene/Solr QA commented on LUCENE-9328:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} LUCENE-9328 does not apply to master. Rebase required? Wrong
Branch? See
https://wiki.apache.org/lucene-java/HowToContribute#Contributing_your_work for
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-9328 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13002385/LUCENE-9328.patch |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/271/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> SortingGroupHead to reuse DocValues
> ---
>
> Key: LUCENE-9328
> URL: https://issues.apache.org/jira/browse/LUCENE-9328
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/grouping
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch,
> LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch,
> LUCENE-9328.patch, LUCENE-9328.patch
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> That's why
> https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob edited a comment on pull request #1500: Backport LUCENE-9350 to branch_8_5
madrob edited a comment on pull request #1500: URL: https://github.com/apache/lucene-solr/pull/1500#issuecomment-626003039 > Can we change it to build the automaton directly in FuzzyQuery.visit() Sure, I dropped the QueryVisitor changes and we do this now. I think the changes to use a Supplier in FuzzyTermsEnum are still ok? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9365) Fuzzy query has a false negative when prefix length == search term length
[
https://issues.apache.org/jira/browse/LUCENE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102958#comment-17102958
]
Mike Drob commented on LUCENE-9365:
---
FuzzyQuery currently has checks for `prefix >= termLength` and collapses to a
SingleTermEnum for that case. I would be in favor of enhancing prefix query for
this use case instead of trying to figure out how to make fuzzy query work with
it.
> Fuzzy query has a false negative when prefix length == search term length
> --
>
> Key: LUCENE-9365
> URL: https://issues.apache.org/jira/browse/LUCENE-9365
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/query/scoring
>Reporter: Mark Harwood
>Priority: Major
>
> When using FuzzyQuery the search string `bba` does not match doc value `bbab`
> with an edit distance of 1 and prefix length of 3.
> In FuzzyQuery an automaton is created for the "suffix" part of the search
> string which in this case is an empty string.
> In this scenario maybe the FuzzyQuery should rewrite to a WildcardQuery of
> the following form :
> {code:java}
> searchString + "?"
> {code}
> .. where there's an appropriate number of ? characters according to the edit
> distance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9328) SortingGroupHead to reuse DocValues
[ https://issues.apache.org/jira/browse/LUCENE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated LUCENE-9328: - Attachment: LUCENE-9328.patch Status: Patch Available (was: Patch Available) > SortingGroupHead to reuse DocValues > --- > > Key: LUCENE-9328 > URL: https://issues.apache.org/jira/browse/LUCENE-9328 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/grouping >Reporter: Mikhail Khludnev >Assignee: Mikhail Khludnev >Priority: Minor > Attachments: LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch, > LUCENE-9328.patch, LUCENE-9328.patch, LUCENE-9328.patch > > Time Spent: 1h 50m > Remaining Estimate: 0h > > That's why > https://issues.apache.org/jira/browse/LUCENE-7701?focusedCommentId=17084365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17084365 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe opened a new pull request #1501: SOLR-13289: Add Refguide changes
tflobbe opened a new pull request #1501: URL: https://github.com/apache/lucene-solr/pull/1501 Reference guide changes for SOLR-13289 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe commented on a change in pull request #1456: SOLR-13289: Support for BlockMax WAND
tflobbe commented on a change in pull request #1456:
URL: https://github.com/apache/lucene-solr/pull/1456#discussion_r422397622
##
File path: solr/solrj/src/test/org/apache/solr/common/util/TestJavaBinCodec.java
##
@@ -242,6 +243,7 @@ public void testBackCompatForSolrDocumentWithChildDocs()
throws IOException {
}
@Test
+ @Ignore("This test compares binaries, which change due to SOLR-13289")
Review comment:
I fixed this test.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13289) Support for BlockMax WAND
[ https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102987#comment-17102987 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-13289: -- Docs in https://github.com/apache/lucene-solr/pull/1501 > Support for BlockMax WAND > - > > Key: SOLR-13289 > URL: https://issues.apache.org/jira/browse/SOLR-13289 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: SOLR-13289.patch, SOLR-13289.patch > > Time Spent: 3.5h > Remaining Estimate: 0h > > LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to > expose this via Solr. When enabled, the numFound returned will not be exact. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14465) Reproducing seed in FuzzySearchTest
[ https://issues.apache.org/jira/browse/SOLR-14465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob resolved SOLR-14465. -- Fix Version/s: master (9.0) Resolution: Fixed > Reproducing seed in FuzzySearchTest > --- > > Key: SOLR-14465 > URL: https://issues.apache.org/jira/browse/SOLR-14465 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Affects Versions: master (9.0) >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > Fix For: master (9.0) > > > reproduce with: ant test -Dtestcase=FuzzySearchTest > -Dtests.method=testTooComplex -Dtests.seed=B6A1F20B2D413B4 > -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true > -Dtests.locale=yue-Hant-HK -Dtests.timezone=America/Dawson > -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > > [~romseygeek] [~mdrob] My guess is that changes in LUCENE-9350/LUCENE-9068 > changed the exception returned, but haven't looked very closely. > [junit4] FAILURE 3.01s | FuzzySearchTest.testTooComplex <<< > [junit4] > Throwable #1: junit.framework.AssertionFailedError: Unexpected > exception type, expected RemoteSolrException but got > org.apache.solr.client.solrj.SolrServerException: No live SolrServers > available to handle this request:[http://127.0.0.1:51202/solr/c1] > [junit4] > at > __randomizedtesting.SeedInfo.seed([B6A1F20B2D413B4:DDC85504AD0720FE]:0) > [junit4] > at > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2751) > [junit4] > at > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2739) > [junit4] > at > org.apache.solr.search.FuzzySearchTest.testTooComplex(FuzzySearchTest.java:64) > [junit4] > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [junit4] > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [junit4] > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [junit4] > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > [junit4] > at java.base/java.lang.Thread.run(Thread.java:834) > [junit4] > Caused by: org.apache.solr.client.solrj.SolrServerException: No > live SolrServers available to handle this > request:[http://127.0.0.1:51202/solr/c1] > [junit4] > at > org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:345) > [junit4] > at > org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1147) > [junit4] > at > org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:910) > [junit4] > at > org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:842) > [junit4] > at > org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) > [junit4] > at > org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1004) > [junit4] > at > org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1019) > [junit4] > at > org.apache.solr.search.FuzzySearchTest.lambda$testTooComplex$0(FuzzySearchTest.java:64) > [junit4] > at > org.apache.lucene.util.LuceneTestCase._expectThrows(LuceneTestCase.java:2869) > [junit4] > at > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2744) > [junit4] > ... 41 more > [junit4] > Caused by: > org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException: > Error from server at http://127.0.0.1:51202/solr/c1: Term too complex: > headquarters(在日米海軍横須賀基地司令部庁舎/旧横須賀鎮守府会議所・横須賀海軍艦船部) > [junit4] > at > org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:665) > [junit4] > at > org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:265) > [junit4] > at org.apache.solr.client.solrj.impl.HttpSolrClient.request( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] CaoManhDat commented on a change in pull request #1470: SOLR-14354: Async or using threads in better way for HttpShardHandler
CaoManhDat commented on a change in pull request #1470:
URL: https://github.com/apache/lucene-solr/pull/1470#discussion_r422459139
##
File path:
solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
##
@@ -130,77 +134,64 @@ public void submit(final ShardRequest sreq, final String
shard, final Modifiable
final Tracer tracer = GlobalTracer.getTracer();
final Span span = tracer != null ? tracer.activeSpan() : null;
-Callable task = () -> {
+params.remove(CommonParams.WT); // use default (currently javabin)
+params.remove(CommonParams.VERSION);
+QueryRequest req = makeQueryRequest(sreq, params, shard);
+req.setMethod(SolrRequest.METHOD.POST);
- ShardResponse srsp = new ShardResponse();
- if (sreq.nodeName != null) {
-srsp.setNodeName(sreq.nodeName);
- }
- srsp.setShardRequest(sreq);
- srsp.setShard(shard);
- SimpleSolrResponse ssr = new SimpleSolrResponse();
- srsp.setSolrResponse(ssr);
- long startTime = System.nanoTime();
+LBSolrClient.Req lbReq =
httpShardHandlerFactory.newLBHttpSolrClientReq(req, urls);
+
+ShardResponse srsp = new ShardResponse();
+if (sreq.nodeName != null) {
+ srsp.setNodeName(sreq.nodeName);
+}
+srsp.setShardRequest(sreq);
+srsp.setShard(shard);
+SimpleSolrResponse ssr = new SimpleSolrResponse();
+srsp.setSolrResponse(ssr);
+
+pending.incrementAndGet();
+// if there are no shards available for a slice, urls.size()==0
+if (urls.size() == 0) {
+ // TODO: what's the right error code here? We should use the same thing
when
Review comment:
I do not, just copied and pasted from the old code.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
