Not to say it's what you're running into here, but I've seen this in
the past when the 'signJarsPublication' task is waiting for your gpg
passphrase on stdin, and times out. You can use gpg-agent or other
setups to avoid entering your passphrase mid-Gradle execution, but
I've found that to be a bi
Hi Anshum,
I've faced several issues in the past in that same step, and have found a
workaround that works for me reliably. But, that's specific to Linux. In
case you are continuing to face difficulties, I can volunteer to sync up
with you and take it forward on my end.
Thanks and regards,
Ishan
O
After some conf changes recommended by Jan and Jason, it seems like I've
resolved the issue.
Re-running the RC build now but thanks for the offer, Ishan! :)
On Mon, Aug 19, 2024 at 7:22 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> Hi Anshum,
> I've faced several issues in the pa
Hi Christos,
> I am just not very happy with the repetitive constraints and the need to
> include transitive dependencies in the version catalog whenever there is a
> version mismatch that needs to be synced.
I share your pain - there is added verbosity here. I haven't found an
elegant way to d
We're encountering a relatively large amount of "humongous object"
allocation with larger cores. For just under 32G configured heap,
G1HeapRegionSize seems to default to 8M or 16M depending on jdk
version. For 100M docs in a shard (e.g.), the long[] backing a
FixedBitSet (BitDocSet) will be ~12M, c
On Mon, Aug 19, 2024 at 2:32 PM Michael Gibney
wrote:
> For a more robust solution than fussing with G1HeapRegionSize, I'm
> wondering if it might be appropriate to change the implementation of
> BitDocSet so that larger instances will be backed by an array of
> multiple smaller FixedBitSet instan
