[jira] [Commented] (SOLR-17040) UpdateLog refactor to use read/write locks

["Alex Deparvu (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782300#comment-17782300 ] 

Alex Deparvu commented on SOLR-17040:
-------------------------------------

thank you [~krisden] for the help here (especially debunking the async profiler). I will close this jira as the results are not the expected ones. I don't see any of the UpdateLog blocking anymore in the profiling data, but things are not faster.
I agree the incredible amount of objects generated is very interesting to investigate, it deserves a dedicated jira where we can continue this side of the benchmark results.

> UpdateLog refactor to use read/write locks
> ------------------------------------------
>
>                 Key: SOLR-17040
>                 URL: https://issues.apache.org/jira/browse/SOLR-17040
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Alex Deparvu
>            Assignee: Alex Deparvu
>            Priority: Major
>         Attachments: Screenshot 2023-10-19 at 13.52.22.png, Screenshot 2023-10-19 at 13.55.54.png, jfr-locks-main.png, jfr-locks-patch.png
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Proposing a change to refactor the UpdateLog from all `synchronized (this)` blocks to read/write locks.
> Will post some benchmark results for evaluation if this is a useful change or not.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org