[clang] [clang][RISCV] Update vcpop.v C interface to follow the nameing convention (PR #94318)
https://github.com/4vtomat closed https://github.com/llvm/llvm-project/pull/94318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[jira] [Commented] (CASSANDRA-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852731#comment-17852731
]
Brandon Williams commented on CASSANDRA-19445:
--
I don't think we need to shave the bug/improvement yak for pushing down a log
statement, it should be fine in 4.1 and 5.0.
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Assignee: Tommy Stendahl
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: patch-4.1.txt, patch-5.0.txt, patch-trunk.txt,
> paxos-entry.txt, paxos-multiple.txt
>
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19683) Investigate dtest timeouts after CASSANDRA-19534
[ https://issues.apache.org/jira/browse/CASSANDRA-19683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19683: - Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: Test/dtest/python Discovered By: DTest Fix Version/s: 5.0-rc Severity: Normal Assignee: Brandon Williams Status: Open (was: Triage Needed) > Investigate dtest timeouts after CASSANDRA-19534 > > > Key: CASSANDRA-19683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19683 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python > Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-rc > > > We have seen increased dtest timeouts that don't appear to be environmental: > https://app.circleci.com/pipelines/github/driftx/cassandra/1651/workflows/738d1c92-0ffe-45e7-8ad4-f2646170ba76 > https://ci-cassandra.apache.org/job/Cassandra-5.0/238/ -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
RE: [External] Re: [PATCH 2/3] tools: binman: fix deprecated Python ConfigParser methods
Hi Simon, > -Original Message- > From: Simon Glass > Sent: Tuesday, June 4, 2024 9:14 PM > To: Maier, Brandon L Collins > Cc: u-boot@lists.denx.de > Subject: [External] Re: [PATCH 2/3] tools: binman: fix deprecated Python > ConfigParser methods > > Hi Brandon, > > On Tue, 4 Jun 2024 at 10:16, Brandon Maier > wrote: > > > > The method `ConfigParser.readfp()` is marked deprecated[1]. > > > > In Python 3.12 this method have been removed, so replace it with > > `ConfigParser.read_file()`. > > > > [1] > https://docs.python.org/3.11/library/configparser.html#configparser.ConfigParser.read_file > > Signed-off-by: Brandon Maier > > CC: Simon Glass > > --- > > tools/buildman/bsettings.py | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Reviewed-by: Simon Glass > > Does this still work in earlier Pythons? The Python docs say ConfigParser.read_file() was added in Python 3.2. The tools/buildman/pyproject.toml says `requires-python = ">=3.7"` so I assume this is fine. > > Regards, > Simon
[jira] [Updated] (CASSANDRA-19681) Debian repository is missing 3.11.17 package
[
https://issues.apache.org/jira/browse/CASSANDRA-19681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19681:
-
Fix Version/s: 3.11.17
(was: NA)
> Debian repository is missing 3.11.17 package
>
>
> Key: CASSANDRA-19681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19681
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.17
>
>
> The Debian package for Cassandra 3.11.17 is missing from the JFrog
> artifactory. The [package
> index|https://apache.jfrog.io/artifactory/cassandra-deb/dists/311x/main/binary-amd64/Packages]
> is still referencing version 3.11.16:
> {code}
> Package: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra_3.11.16_all.deb
> ...
> Package: cassandra-tools
> Source: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra-tools_3.11.16_all.deb
> ...
> {code}
> When I tried to install the latest C* 3.11 version on Ubuntu, 3.11.16 got
> installed instead of 3.11.17.
> Note that this was originally reported by [Roman on Stack
> Exchange|https://dba.stackexchange.com/questions/340007/].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19681) Debian repository is missing 3.11.17 package
[
https://issues.apache.org/jira/browse/CASSANDRA-19681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19681:
-
Fix Version/s: NA
(was: 3.11.x)
> Debian repository is missing 3.11.17 package
>
>
> Key: CASSANDRA-19681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19681
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: NA
>
>
> The Debian package for Cassandra 3.11.17 is missing from the JFrog
> artifactory. The [package
> index|https://apache.jfrog.io/artifactory/cassandra-deb/dists/311x/main/binary-amd64/Packages]
> is still referencing version 3.11.16:
> {code}
> Package: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra_3.11.16_all.deb
> ...
> Package: cassandra-tools
> Source: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra-tools_3.11.16_all.deb
> ...
> {code}
> When I tried to install the latest C* 3.11 version on Ubuntu, 3.11.16 got
> installed instead of 3.11.17.
> Note that this was originally reported by [Roman on Stack
> Exchange|https://dba.stackexchange.com/questions/340007/].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19681) Debian repository is missing 3.11.17 package
[
https://issues.apache.org/jira/browse/CASSANDRA-19681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19681:
-
Resolution: Fixed
Status: Resolved (was: Open)
I resolved this and tested that 3.11.17 gets installed from the 311x repo.
I suspect the failure from CASSANDRA-19561 resulted in this being uploaded into
the wrong subdirectory, which I have corrected.
> Debian repository is missing 3.11.17 package
>
>
> Key: CASSANDRA-19681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19681
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x
>
>
> The Debian package for Cassandra 3.11.17 is missing from the JFrog
> artifactory. The [package
> index|https://apache.jfrog.io/artifactory/cassandra-deb/dists/311x/main/binary-amd64/Packages]
> is still referencing version 3.11.16:
> {code}
> Package: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra_3.11.16_all.deb
> ...
> Package: cassandra-tools
> Source: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra-tools_3.11.16_all.deb
> ...
> {code}
> When I tried to install the latest C* 3.11 version on Ubuntu, 3.11.16 got
> installed instead of 3.11.17.
> Note that this was originally reported by [Roman on Stack
> Exchange|https://dba.stackexchange.com/questions/340007/].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18762) Repair triggers OOM with direct buffer memory
[
https://issues.apache.org/jira/browse/CASSANDRA-18762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852388#comment-17852388
]
Brandon Williams commented on CASSANDRA-18762:
--
Does CASSANDRA-19336 not solve this?
> Repair triggers OOM with direct buffer memory
> -
>
> Key: CASSANDRA-18762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18762
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brad Schoening
>Priority: Normal
> Labels: OutOfMemoryError
> Attachments: Cluster-dm-metrics-1.PNG,
> image-2023-12-06-15-28-05-459.png, image-2023-12-06-15-29-31-491.png,
> image-2023-12-06-15-58-55-007.png
>
>
> We are seeing repeated failures of nodes with 16GB of heap on a VM with 32GB
> of physical RAM due to direct memory. This seems to be related to
> CASSANDRA-15202 which moved Merkel trees off-heap in 4.0. Using Cassandra
> 4.0.6 with Java 11.
> {noformat}
> 2023-08-09 04:30:57,470 [INFO ] [AntiEntropyStage:1] cluster_id=101
> ip_address=169.0.0.1 RepairSession.java:202 - [repair
> #5e55a3b0-366d-11ee-a644-d91df26add5e] Received merkle tree for table_a from
> /169.102.200.241:7000
> 2023-08-09 04:30:57,567 [INFO ] [AntiEntropyStage:1] cluster_id=101
> ip_address=169.0.0.1 RepairSession.java:202 - [repair
> #5e0d2900-366d-11ee-a644-d91df26add5e] Received merkle tree for table_b from
> /169.93.192.29:7000
> 2023-08-09 04:30:57,568 [INFO ] [AntiEntropyStage:1] cluster_id=101
> ip_address=169.0.0.1 RepairSession.java:202 - [repair
> #5e1dcad0-366d-11ee-a644-d91df26add5e] Received merkle tree for table_c from
> /169.104.171.134:7000
> 2023-08-09 04:30:57,591 [INFO ] [AntiEntropyStage:1] cluster_id=101
> ip_address=169.0.0.1 RepairSession.java:202 - [repair
> #5e69a0e0-366d-11ee-a644-d91df26add5e] Received merkle tree for table_b from
> /169.79.232.67:7000
> 2023-08-09 04:30:57,876 [INFO ] [Service Thread] cluster_id=101
> ip_address=169.0.0.1 GCInspector.java:294 - G1 Old Generation GC in 282ms.
> Compressed Class Space: 8444560 -> 8372152; G1 Eden Space: 7809794048 -> 0;
> G1 Old Gen: 1453478400 -> 820942800; G1 Survivor Space: 419430400 -> 0;
> Metaspace: 80411136 -> 80176528
> 2023-08-09 04:30:58,387 [ERROR] [AntiEntropyStage:1] cluster_id=101
> ip_address=169.0.0.1 JVMStabilityInspector.java:102 - OutOfMemory error
> letting the JVM handle the error:
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
> at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:118)
> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:318)
> at org.apache.cassandra.utils.MerkleTree.allocate(MerkleTree.java:742)
> at
> org.apache.cassandra.utils.MerkleTree.deserializeOffHeap(MerkleTree.java:780)
> at org.apache.cassandra.utils.MerkleTree.deserializeTree(MerkleTree.java:751)
> at org.apache.cassandra.utils.MerkleTree.deserialize(MerkleTree.java:720)
> at org.apache.cassandra.utils.MerkleTree.deserialize(MerkleTree.java:698)
> at
> org.apache.cassandra.utils.MerkleTrees$MerkleTreesSerializer.deserialize(MerkleTrees.java:416)
> at
> org.apache.cassandra.repair.messages.ValidationResponse$1.deserialize(ValidationResponse.java:100)
> at
> org.apache.cassandra.repair.messages.ValidationResponse$1.deserialize(ValidationResponse.java:84)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePost40(Message.java:782)
> at org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:642)
> at
> org.apache.cassandra.net.InboundMessageHandler$LargeMessage.deserialize(InboundMessageHandler.java:364)
> at
> org.apache.cassandra.net.InboundMessageHandler$LargeMessage.access$1100(InboundMessageHandler.java:317)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessLargeMessage.provideMessage(InboundMessageHandler.java:504)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:429)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)no* further _formatting_ is
> done here{noformat}
>
>
[jira] [Comment Edited] (CASSANDRA-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852379#comment-17852379 ] Brandon Williams edited comment on CASSANDRA-19679 at 6/5/24 10:48 AM: --- It looks good to me, happy to take a look when we have CI. was (Author: brandon.williams): Looks like this should just apply to 5.0. It looks good to me, happy to take a look when we have CI. > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_before.html, > image-2024-06-04-21-55-34-457.png > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.69%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19679) Stream processing for SimpleRestriction::bindAndGetClusteringElements
[ https://issues.apache.org/jira/browse/CASSANDRA-19679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852379#comment-17852379 ] Brandon Williams commented on CASSANDRA-19679: -- Looks like this should just apply to 5.0. It looks good to me, happy to take a look when we have CI. > Stream processing for SimpleRestriction::bindAndGetClusteringElements > - > > Key: CASSANDRA-19679 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19679 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, alloc_after.html, alloc_before.html, > image-2024-06-04-21-55-34-457.png > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Part 2 (of 2) of low-hanging fruit Stream performance improvements. > The second main Stream contributor to allocations and CPU was > SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of > all allocations for a 50/50 workload. The image attached shows allocation > profiling on _trunk_ (see purple highlighted sections for Stream-related > allocs). > The 'after' profile for a 50/50 workload shows a reduction from 4.58% > allocations down to 1.69%. For a 90/10 (w/r) workload we see 4.28% decrease > to 1.10%. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [Freedos-user] "fdnpkg update" not working
Well, a pox on me for thinking I could fix something when I clearly have no idea what I'm doing. I guess there was a reason why the FreeDOS developers disabled "physical hardware networking" even though I was trying to run it on 86Box. I think there are still a number of kinks to work out in that particular department... I went back and spun up a fresh FreeDOS VM on VirtualBox, and fdnpkg update works correctly that way. Why it's flaky with 86Box, I have no clue... (Sigh) Brandon Taylor From: Jerome Shidel via Freedos-user Sent: Tuesday, June 4, 2024 7:57 PM To: Discussion and general questions about FreeDOS. Cc: Jerome Shidel Subject: Re: [Freedos-user] "fdnpkg update" not working On Jun 4, 2024, at 7:33 PM, Brandon Taylor via Freedos-user wrote: I've tried several times lately to run fdnpkg update, but the command hangs repeatedly at Loading http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/base... ` and no progress is ever made. I've tried pinging www.ibiblio.org and discovered that it's up and running. The nearest I can figure is that, somehow, the FreeDOS repository on that server may have disappeared. Can anyone out there confirm whether it's working? When you browse that directory on ibiblio, that is the repository directory for that group “base”. However, server can do some odd things sometimes. So, I double checked by running FDNPKG update on FreeDOS 1.3. No issues detected. Try clearing the FDNPKG cache “see its help /?” If that does not help, it could be networking related. Something like a virtual machines host operating system firewall settings. If it's not, where can I find an acceptable mirror, and how do I configure the fdnpkg program to access that mirror? I upload all packages in the FreeDOS update repository used by FDNPKG on ibiblio. Those packages and several more are also uploaded to my “unofficial” repository on my server. It is not technically a mirror. But, it does get all the same updates as on ibiblio. Actually, since the repository management software makes a few changes to new uploads. I usually upload them to my server first. Then download the modified package and push it to ibiblio. That way the management software there sees the needed changes have been made and include the package as-is. You can browse the repository on my server at https://fd.lod.bz/repos/current/ or through html https://fd.lod.bz/repos/current/pkg-html/ But, accessing that server through the domain name https://fd.lod.bz/ will force a TLS connection. The reason for that is because of how search engines have been punishing domains that allow non-TLS connections. FDNPKG does not support TLS. Recently, I setup an alternate subdomain specifically for compatibility with FDNPKG. At present, its directory structure is not browsable. That subdomain does have access to the same repository on that server and you can browse the html index at http://dos.lod.bz/repos/current/pkg-html/ Because I think you are having a local problem, I don’t think it will help. But, you are welcome to pull updates from my server. It is relatively easy to make the adjustments to your system for that. In your \FREEDOS\BIN directory there is a FDNPKG.CFG file. Make a copy of the current one before you start editing it. That way you can always switch back if you want. Towards the end of the file you will see a bunch of urls for each of the groups, including the one for base you mentioned. You just need to change the main part of the url for each link. For example, to pull items in the base group from my server, you would change that link to: http://dos.lod.bz/repos/current/base And so on for each link. Brandon Taylor :-) Jerome ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[jira] [Assigned] (CASSANDRA-19681) Debian repository is missing 3.11.17 package
[
https://issues.apache.org/jira/browse/CASSANDRA-19681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-19681:
Assignee: Brandon Williams
> Debian repository is missing 3.11.17 package
>
>
> Key: CASSANDRA-19681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19681
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x
>
>
> The Debian package for Cassandra 3.11.17 is missing from the JFrog
> artifactory. The [package
> index|https://apache.jfrog.io/artifactory/cassandra-deb/dists/311x/main/binary-amd64/Packages]
> is still referencing version 3.11.16:
> {code}
> Package: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra_3.11.16_all.deb
> ...
> Package: cassandra-tools
> Source: cassandra
> Version: 3.11.16
> ...
> Filename: pool/main/c/cassandra/cassandra-tools_3.11.16_all.deb
> ...
> {code}
> When I tried to install the latest C* 3.11 version on Ubuntu, 3.11.16 got
> installed instead of 3.11.17.
> Note that this was originally reported by [Roman on Stack
> Exchange|https://dba.stackexchange.com/questions/340007/].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19022) Nodetool gcstats correctly displays Direct Memory usage and supports printing in table format
[
https://issues.apache.org/jira/browse/CASSANDRA-19022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19022:
-
Fix Version/s: 5.x
(was: 5.1)
> Nodetool gcstats correctly displays Direct Memory usage and supports printing
> in table format
> -
>
> Key: CASSANDRA-19022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19022
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>
> If {{io.netty.maxDirectMemory}} is not specified, Netty defaults the limit to
> the max heap size. Thus, direct memory in use can be significant.
> However, trying this on two different platform and the result returned in
> gcstats is always -1:
> {noformat}
> Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms)
> GC Reclaimed (MB) Collections Direct Memory Bytes
> 2792770717 274 665186 54
> 412762880890246120 -1{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[clang] [clang][RISCV] Update vcpop.v C interface to follow the nameing convention (PR #94318)
4vtomat wrote: > Could you give few more word on the description to mention we missed that in > the vector crpyto intrinsic proposal, and it's fixing but rather than > incompatible/breaking change for the intrinsic API? Updated description. We are missing `vcpop.v` in the rvv_intrinsic_doc, so I think we don't break anything lol~ https://github.com/llvm/llvm-project/pull/94318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][RISCV] Update vcpop.v C interface to follow the nameing convention (PR #94318)
https://github.com/4vtomat edited https://github.com/llvm/llvm-project/pull/94318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][RISCV] Update vcpop.v C interface to follow the nameing convention (PR #94318)
https://github.com/4vtomat edited https://github.com/llvm/llvm-project/pull/94318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[Freedos-user] "fdnpkg update" not working
I've tried several times lately to run fdnpkg update, but the command hangs repeatedly at Loading http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/base... ` and no progress is ever made. I've tried pinging www.ibiblio.org and discovered that it's up and running. The nearest I can figure is that, somehow, the FreeDOS repository on that server may have disappeared. Can anyone out there confirm whether it's working? If it's not, where can I find an acceptable mirror, and how do I configure the fdnpkg program to access that mirror? Brandon Taylor ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[jira] [Commented] (CASSANDRA-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852210#comment-17852210 ] Brandon Williams commented on CASSANDRA-19676: -- I'm +1 on 5.0 > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 10m --maxwlat 10 -r 0.1 --rate 2 > --compaction twcs > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[MariaDB developers] Re: [PATCH] MDEV-21322: Report slave progress to the master
On Tue, Jun 4, 2024 at 2:51 PM Kristian Nielsen
wrote:
> Brandon Nesterenko writes:
>
> > were some additional
> > synchronization changes that went alongside the use of LOCK_thd_data, so
> it
> > would be good if
> > you could go over at least the code changes again.
>
> > diff --git a/sql/sql_repl.cc b/sql/sql_repl.cc
> > index 18a52dc07ad..47f789de751 100644
> > --- a/sql/sql_repl.cc
> > +++ b/sql/sql_repl.cc
> > @@ -2294,10 +2294,19 @@ send_event_to_slave(binlog_send_info *info,
> Log_event_type event_type,
> >
> >if (info->thd->slave_info)
> >{
> > -strncpy(info->thd->slave_info->gtid_state_sent.log_file,
> > -info->log_file_name + info->dirlen,
> > -strlen(info->log_file_name) - info->dirlen);
> > -info->thd->slave_info->gtid_state_sent.log_pos= pos;
> > +char *new_log_flie= info->log_file_name + info->dirlen;
> > +size_t log_file_size= strlen(info->log_file_name) - info->dirlen;
>
> Hm, spelling mistake s/new_log_flie/new_log_file/.
> And you can simpler do just:
>
> size_t log_file_size= strlen(new_log_file);
>
> But more importantly, I almost didn't want to mention the need for locking
> around this, it's just more overhead, that is going to be added for _every_
> transaction in _every_ slave dump thread.
>
> Is it really worth it to add this overhead? Isn't all of the info added to
> SHOW SLAVE STATUS already available directly on the slave? Just query the
> slave with SHOW SLAVE STATUS and all the information should already be
> available, without introducing ever more overhead in the replication layer.
>
> I browsed through the comments in
> https://jira.mariadb.org/browse/MDEV-21322, but didn't see any
> justification
> for this over just querying the slaves and avoiding the overhead. Also I
> don't recall seeing any architecture review / discussion of this?
>
> So is this MDEV even needed / justified to add to the server?
>
That's a fair concern. I took your advice in my latest patch and first
check the log file has changed before actually locking to change it,
but it'd still be good to quantify the actual overhead induced here.
It seems the patch started from MDEV-18475, and somewhere along
the line MDEV-21322 was filed which seems to duplicate the ticket
exactly, it seems. And the justification from MDEV-18475 is "it would be
nice".
I don't see any harm in letting it go out for the preview branch release
while we work out the concerns, and in the end, we can pull it if the
overhead ends up outweighing a "niceness". It may also be well
received (I'm also curious, do our users actually test out our preview
branches?)
>
> >> > +--let $nextval= `SELECT max(a)+1 from t1`
> >> > +--eval insert into t1 values ($nextval)
> >>
> >> Is there a reason here to use separate --let and --eval? And not just:
> >>
> >> INSERT INTO t1 SELECT max(a)+1 FROM t1;
> >>
> >
> > I like seeing the actual number value for cross referencing the values
> > potentially
> > in the table (e.g. if manually debugging and running a SELECT).
>
> Ok, sure, then it's fine.
>
> >> Again, sync_with_master_gtid.inc on the slave will not guarantee that
> the
> >> master saw the ack yet, even though it will be a rare race when it
> doesn't
> >> happen.
> >> So you'd need to wait for the expected value here with
> wait_condition.inc
> >> or somilar instead, I think.
> >> Probably the same in subsequent parts of the test case.
> >>
> >
> > This one is guaranteed that the master saw the ACK implicitly, as the
> > transaction
> > has returned from commit (which only happens in the case of ACK
> received, or
> > timeout (which would invalidate the test anyway)).
>
> Ah, yes, I missed that. Ok, that probably apply in a number of places I
> otherwise thought could be non-deterministic.
>
> > Right.I tried pretty hard up-front to make the test as deterministic as
> > possible, though
> > I did fix one more spot based on your previous catch of
> > rpl_semi_sync_master_clients
> > not in sync with Sync_Status :)
>
> One thing that I have found effective is to run eg:
>
> ./mysql-test-run.pl --mem rpl.rpl_show_slave_hosts{,,,} --parallel=12
> --repeat=1000
>
> and just let it run overnight or something, I've found that tends to
> trigger
> most non-deterministic failures that will be seen in buildbot (though not
> all). This for my 4-core/8-thread laptop.
>
I usually do that as well (I did it for this ticket too, I suppose the race
condition
you found just was too rare for my laptop to find)
>
> - Kristian.
>
___
developers mailing list -- developers@lists.mariadb.org
To unsubscribe send an email to developers-le...@lists.mariadb.org
[clang] [clang][RISCV] Enable RVV with function attribute __attribute__((target("arch=+v"))) (PR #83674)
https://github.com/4vtomat edited https://github.com/llvm/llvm-project/pull/83674 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][RISCV] Enable RVV with function attribute __attribute__((target("arch=+v"))) (PR #83674)
4vtomat wrote:
> FYI, the example code you shown doesn't compile anymore:
> https://godbolt.org/z/ooTWEGejf
>
> This feature is quite important, without it we can't compile in RVV by
> default in a lot of libraries, e.g. simdutf, flac, ...
I guess it should be `__attribute__((target("arch=+zve32x")))` rather then
`__attribute__((target("+zve32x")))`, sorry for misleading in the description,
let me fix it.
Btw, you can check the test case in this PR to see the correct usage.
https://github.com/llvm/llvm-project/pull/83674
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH 1/1] tools: patman: fix `pip install` with Python 3.12
Installing patman with `cd ./tools/patman && pip install -e .` fails with the error below. As described in the error output, the license line is not allowed to be only defined in the setup.py. > $ cd ./tools/patman && pip install -e . > Obtaining file:///.../u-boot/tools/patman > Installing build dependencies ... done > Checking if build backend supports build_editable ... done > Getting requirements to build editable ... error > error: subprocess-exited-with-error > > × Getting requirements to build editable did not run successfully. > │ exit code: 1 > ╰─> [61 lines of output] > > /tmp/pip-build-env-mqjvnmz8/overlay/lib/python3.12/site-packages/setuptools/config/_apply_pyprojecttoml.py:76: > _MissingDynamic: `license` defined outside of `pyproject.toml` is > ignored. > !! > > > > The following seems to be defined outside of `pyproject.toml`: > > `license = 'GPL-2.0+'` > > According to the spec (see the link below), however, setuptools CANNOT > consider this value unless `license` is listed as `dynamic`. > > > https://packaging.python.org/en/latest/specifications/pyproject-toml/#declaring-project-metadata-the-project-table > > To prevent this problem, you can list `license` under `dynamic` or > alternatively > remove the `[project]` table from your file and rely entirely on other > means of > configuration. > > > > !! Signed-off-by: Brandon Maier CC: Simon Glass --- tools/patman/pyproject.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/patman/pyproject.toml b/tools/patman/pyproject.toml index fcefcf66960..9e6079cb57e 100644 --- a/tools/patman/pyproject.toml +++ b/tools/patman/pyproject.toml @@ -17,6 +17,7 @@ classifiers = [ "License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)", "Operating System :: OS Independent", ] +dynamic = ["license"] [project.urls] "Homepage" = "https://docs.u-boot.org/en/latest/develop/patman.html; -- 2.45.1
[PATCH 3/3] tools: patman: fix deprecated Python ConfigParser methods
The method `ConfigParser.readfp()` is marked deprecated[1].
In Python 3.12 this method have been removed, so replace it with
`ConfigParser.read_file()`.
[1]
https://docs.python.org/3.11/library/configparser.html#configparser.ConfigParser.readfp
Signed-off-by: Brandon Maier
CC: Simon Glass
---
tools/patman/settings.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/patman/settings.py b/tools/patman/settings.py
index 636983e32da..68c93e313b3 100644
--- a/tools/patman/settings.py
+++ b/tools/patman/settings.py
@@ -59,25 +59,25 @@ class _ProjectConfigParser(ConfigParser.ConfigParser):
# Check to make sure that bogus project gets general alias.
>>> config = _ProjectConfigParser("zzz")
->>> config.readfp(StringIO(sample_config))
+>>> config.read_file(StringIO(sample_config))
>>> str(config.get("alias", "enemies"))
'Evil '
# Check to make sure that alias gets overridden by project.
>>> config = _ProjectConfigParser("sm")
->>> config.readfp(StringIO(sample_config))
+>>> config.read_file(StringIO(sample_config))
>>> str(config.get("alias", "enemies"))
'Green G. '
# Check to make sure that settings get merged with project.
>>> config = _ProjectConfigParser("linux")
->>> config.readfp(StringIO(sample_config))
+>>> config.read_file(StringIO(sample_config))
>>> sorted((str(a), str(b)) for (a, b) in config.items("settings"))
[('am_hero', 'True'), ('check_patch_use_tree', 'True'), ('process_tags',
'False')]
# Check to make sure that settings works with unknown project.
>>> config = _ProjectConfigParser("unknown")
->>> config.readfp(StringIO(sample_config))
+>>> config.read_file(StringIO(sample_config))
>>> sorted((str(a), str(b)) for (a, b) in config.items("settings"))
[('am_hero', 'True')]
"""
--
2.45.1
[PATCH 2/3] tools: binman: fix deprecated Python ConfigParser methods
The method `ConfigParser.readfp()` is marked deprecated[1]. In Python 3.12 this method have been removed, so replace it with `ConfigParser.read_file()`. [1] https://docs.python.org/3.11/library/configparser.html#configparser.ConfigParser.readfp Signed-off-by: Brandon Maier CC: Simon Glass --- tools/buildman/bsettings.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py index e225ac2ca0f..aea724fc559 100644 --- a/tools/buildman/bsettings.py +++ b/tools/buildman/bsettings.py @@ -29,7 +29,7 @@ def setup(fname=''): settings.read(config_fname) def add_file(data): -settings.readfp(io.StringIO(data)) +settings.read_file(io.StringIO(data)) def get_items(section): """Get the items from a section of the config. -- 2.45.1
[PATCH 1/3] tools: binman: fix deprecated Python unittest methods
The methods `unittest.assertEquals()` and
`unittest.assertRegexpMatches()` are marked deprecated[1].
In Python 3.12 these aliases have been removed, so do a sed to replace
them with their new names.
[1] https://docs.python.org/3.11/library/unittest.html#deprecated-aliases
Signed-off-by: Brandon Maier
CC: Simon Glass
CC: Alper Nebi Yasak
---
tools/binman/entry_test.py | 6 +--
tools/binman/fdt_test.py| 48
tools/binman/ftest.py | 42 ++---
tools/buildman/func_test.py | 74 ++---
tools/buildman/test.py | 2 +-
5 files changed, 86 insertions(+), 86 deletions(-)
diff --git a/tools/binman/entry_test.py b/tools/binman/entry_test.py
index ac6582cf86a..40d74d401a2 100644
--- a/tools/binman/entry_test.py
+++ b/tools/binman/entry_test.py
@@ -103,7 +103,7 @@ class TestEntry(unittest.TestCase):
ent = entry.Entry.Create(None, self.GetNode(), 'missing',
missing_etype=True)
self.assertTrue(isinstance(ent, Entry_blob))
-self.assertEquals('missing', ent.etype)
+self.assertEqual('missing', ent.etype)
def testDecompressData(self):
"""Test the DecompressData() method of the base class"""
@@ -111,8 +111,8 @@ class TestEntry(unittest.TestCase):
base.compress = 'lz4'
bintools = {}
base.comp_bintool = base.AddBintool(bintools, '_testing')
-self.assertEquals(tools.get_bytes(0, 1024), base.CompressData(b'abc'))
-self.assertEquals(tools.get_bytes(0, 1024),
base.DecompressData(b'abc'))
+self.assertEqual(tools.get_bytes(0, 1024), base.CompressData(b'abc'))
+self.assertEqual(tools.get_bytes(0, 1024), base.DecompressData(b'abc'))
def testLookupOffset(self):
"""Test the lookup_offset() method of the base class"""
diff --git a/tools/binman/fdt_test.py b/tools/binman/fdt_test.py
index 7ef87295463..564c1770820 100644
--- a/tools/binman/fdt_test.py
+++ b/tools/binman/fdt_test.py
@@ -44,43 +44,43 @@ class TestFdt(unittest.TestCase):
fname = self.GetCompiled('045_prop_test.dts')
dt = FdtScan(fname)
node = dt.GetNode('/binman/intel-me')
-self.assertEquals('intel-me', node.name)
+self.assertEqual('intel-me', node.name)
val = fdt_util.GetString(node, 'filename')
-self.assertEquals(str, type(val))
-self.assertEquals('me.bin', val)
+self.assertEqual(str, type(val))
+self.assertEqual('me.bin', val)
prop = node.props['intval']
-self.assertEquals(fdt.Type.INT, prop.type)
-self.assertEquals(3, fdt_util.GetInt(node, 'intval'))
+self.assertEqual(fdt.Type.INT, prop.type)
+self.assertEqual(3, fdt_util.GetInt(node, 'intval'))
prop = node.props['intarray']
-self.assertEquals(fdt.Type.INT, prop.type)
-self.assertEquals(list, type(prop.value))
-self.assertEquals(2, len(prop.value))
-self.assertEquals([5, 6],
+self.assertEqual(fdt.Type.INT, prop.type)
+self.assertEqual(list, type(prop.value))
+self.assertEqual(2, len(prop.value))
+self.assertEqual([5, 6],
[fdt_util.fdt32_to_cpu(val) for val in prop.value])
prop = node.props['byteval']
-self.assertEquals(fdt.Type.BYTE, prop.type)
-self.assertEquals(chr(8), prop.value)
+self.assertEqual(fdt.Type.BYTE, prop.type)
+self.assertEqual(chr(8), prop.value)
prop = node.props['bytearray']
-self.assertEquals(fdt.Type.BYTE, prop.type)
-self.assertEquals(list, type(prop.value))
-self.assertEquals(str, type(prop.value[0]))
-self.assertEquals(3, len(prop.value))
-self.assertEquals([chr(1), '#', '4'], prop.value)
+self.assertEqual(fdt.Type.BYTE, prop.type)
+self.assertEqual(list, type(prop.value))
+self.assertEqual(str, type(prop.value[0]))
+self.assertEqual(3, len(prop.value))
+self.assertEqual([chr(1), '#', '4'], prop.value)
prop = node.props['longbytearray']
-self.assertEquals(fdt.Type.INT, prop.type)
-self.assertEquals(0x090a0b0c, fdt_util.GetInt(node, 'longbytearray'))
+self.assertEqual(fdt.Type.INT, prop.type)
+self.assertEqual(0x090a0b0c, fdt_util.GetInt(node, 'longbytearray'))
prop = node.props['stringval']
-self.assertEquals(fdt.Type.STRING, prop.type)
-self.assertEquals('message2', fdt_util.GetString(node, 'stringval'))
+self.assertEqual(fdt.Type.STRING, prop.type)
+self.assertEqual('message2', fdt_util.GetString(node, 'stringval'))
prop = node.props['stringarray']
-self.assertEquals(fdt.Type.STRING, prop.type)
-self.assertEquals(list, type(prop.value))
-self.assertEquals(3, len(prop.value))
-self.a
[jira] [Commented] (CASSANDRA-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852104#comment-17852104 ] Brandon Williams commented on CASSANDRA-19676: -- I ran a 5.0 build [here|https://app.circleci.com/pipelines/github/driftx/cassandra/1650/workflows/35a6dff8-a82b-4313-9040-0bee58106498] and got similar results, so I ran a 5.0 baseline [here|https://app.circleci.com/pipelines/github/driftx/cassandra/1651/workflows/738d1c92-0ffe-45e7-8ad4-f2646170ba76] and it looks like these tests were recently broken before this patch. > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: after.png, image-2024-06-02-17-25-25-071.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. > easy-cass-stress command: > $ bin/easy-cass-stress run KeyValue -n 2000k --maxwlat 10 -r 0.1 --rate 5000 > --compaction twcs > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19661) Cannot restart Cassandra 5 after creating a vector table and index
[
https://issues.apache.org/jira/browse/CASSANDRA-19661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852101#comment-17852101
]
Brandon Williams commented on CASSANDRA-19661:
--
I was hoping I could drive this forward by running through
https://docs.llamaindex.ai/en/stable/examples/vector_stores/CassandraIndexDemo/
and getting a reproduction against beta1 or HEAD, but it does not reproduce.
Adding all the text files from test/resources/tokenization/ does not help
either.
> Cannot restart Cassandra 5 after creating a vector table and index
> --
>
> Key: CASSANDRA-19661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19661
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Sergio Rua
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> I'm using llama-index and llama3 to train a model. I'm using a very simple
> code that reads some *.txt files from local and uploads them to Cassandra and
> then creates the index:
>
> {code:java}
> # Create the index from documents
> index = VectorStoreIndex.from_documents(
> documents,
> service_context=vector_store.service_context,
> storage_context=storage_context,
> show_progress=True,
> ) {code}
> This works well and I'm able to use a Chat app to get responses from the
> Cassandra data. however, right after, I cannot restart Cassandra. It'll break
> with the following error:
>
> {code:java}
> INFO [PerDiskMemtableFlushWriter_0:7] 2024-05-23 08:23:20,102
> Flushing.java:179 - Completed flushing
> /data/cassandra/data/gpt/docs_20240523-10c8eaa018d811ef8dadf75182f3e2b4/da-6-bti-Data.db
> (124.236MiB) for commitlog position
> CommitLogPosition(segmentId=1716452305636, position=15336)
> [...]
> WARN [MemtableFlushWriter:1] 2024-05-23 08:28:29,575
> MemtableIndexWriter.java:92 - [gpt.docs.idx_vector_docs] Aborting index
> memtable flush for
> /data/cassandra/data/gpt/docs-aea77a80184b11ef8dadf75182f3e2b4/da-3-bti...{code}
> {code:java}
> java.lang.IllegalStateException: null
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:496)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.VectorPostings.computeRowIds(VectorPostings.java:76)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.OnHeapGraph.writeData(OnHeapGraph.java:313)
> at
> org.apache.cassandra.index.sai.memory.VectorMemoryIndex.writeDirect(VectorMemoryIndex.java:272)
> at
> org.apache.cassandra.index.sai.memory.MemtableIndex.writeDirect(MemtableIndex.java:110)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flushVectorIndex(MemtableIndexWriter.java:192)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:117)
> at
> org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
> at
> org.apache.cassandra.db.compaction.unified.ShardedMultiWriter.commit(ShardedMultiWriter.java:219)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1323)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1222)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
> The table created by the script is as follows:
>
> {noformat}
> CREATE TABLE gpt.docs (
> partition_id text,
> row_id text,
> attributes_blob text,
> body_blob text,
> vector vector,
> metadata_s map,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> AND additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_part
Re: Debian repository intermittent outages
I created https://issues.apache.org/jira/browse/INFRA-25843 to have this looked into. Kind Regards, Brandon On Tue, Jun 4, 2024 at 8:03 AM Kornél Pál wrote: > > Hi, > > The redirection at https://debian.cassandra.apache.org/dists/40x/Release is > very slow, sometimes even connection times out. This makes apt-get update > fail. > > I tried it from multiple locations. > > I don't see any issues with the jfrog site that is the redirection target, > but I would prefer to keep using the official repository URL. > > Could you please check if you are seeing any issues with the redirection site. > > Thank you, > Kornel
[jira] [Updated] (CASSANDRA-19375) Link in docs to Achilles Java Driver links to malicious site
[ https://issues.apache.org/jira/browse/CASSANDRA-19375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19375: - Status: Ready to Commit (was: Review In Progress) > Link in docs to Achilles Java Driver links to malicious site > > > Key: CASSANDRA-19375 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19375 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: PJ Fanning >Assignee: Brad Schoening >Priority: Normal > > https://cassandra.apache.org/doc/4.1/cassandra/getting_started/drivers.html#java > The Achilles link looks dangerous. I tried it and it looked like the link has > been taken over by a malicious user. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19375) Link in docs to Achilles Java Driver links to malicious site
[ https://issues.apache.org/jira/browse/CASSANDRA-19375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19375: - Reviewers: Brandon Williams Status: Review In Progress (was: Patch Available) > Link in docs to Achilles Java Driver links to malicious site > > > Key: CASSANDRA-19375 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19375 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: PJ Fanning >Assignee: Brad Schoening >Priority: Normal > > https://cassandra.apache.org/doc/4.1/cassandra/getting_started/drivers.html#java > The Achilles link looks dangerous. I tried it and it looked like the link has > been taken over by a malicious user. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19375) Link in docs to Achilles Java Driver links to malicious site
[ https://issues.apache.org/jira/browse/CASSANDRA-19375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851843#comment-17851843 ] Brandon Williams commented on CASSANDRA-19375: -- Looks good to me, +1. If you need help deploying the site (see https://github.com/apache/cassandra-website) let me know. > Link in docs to Achilles Java Driver links to malicious site > > > Key: CASSANDRA-19375 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19375 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: PJ Fanning >Assignee: Brad Schoening >Priority: Normal > > https://cassandra.apache.org/doc/4.1/cassandra/getting_started/drivers.html#java > The Achilles link looks dangerous. I tried it and it looked like the link has > been taken over by a malicious user. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19217: - Status: Ready to Commit (was: Review In Progress) > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19217: - Reviewers: Brandon Williams, Brandon Williams Brandon Williams, Brandon Williams (was: Brandon Williams) Status: Review In Progress (was: Patch Available) > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851723#comment-17851723 ] Brandon Williams commented on CASSANDRA-19217: -- Looks good to me; +1 > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19676) Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851703#comment-17851703 ] Brandon Williams commented on CASSANDRA-19676: -- I think 5.0.0 is probably a good place for this; it shouldn't cause a regression and is a performance boost, but if it does happen to regress then catching it in a new release is the best scenario. > Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric > > > Key: CASSANDRA-19676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19676 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Sam Lightfoot >Assignee: Sam Lightfoot >Priority: Normal > Fix For: 5.x > > Attachments: image-2024-06-02-17-25-25-071.png > > Time Spent: 20m > Remaining Estimate: 0h > > On profiling a write-heavy workload (90% writes) using easy-cass-stress, it > became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was > a hot path that ~15% of the CPU cycles of > ModificationStatement::executeWithoutCondition were taken up by (see attached > async-profiler image). > We should convert this stream to a simple for loop, as has been discussed > recently on the mail list. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[Freedos-user] VICTORY! How I got networking operational in 86Box
I've been agonizing over the question of why I can't connect an 86Box virtual machine powered by FreeDOS to the Internet. But now, it seems, I have found a fix, or at least a preliminary one. Using a fine-toothed comb (as it were), I went over the FDAUTO.BAT file and found that it referenced another batch file that handled all of the networking stuff, namely, C:\FREEDOS\BIN\FDNET.BAT. So, going over THAT, I arrived at what I figured was a critical line in the second batch file, which was vinfo /m. Typing this into the command line didn't seem to do anything, but when I typed vinfo /m | echo %errorlevel%, lo and behold, FreeDOS returned the number 5. So, going back into FDNET.BAT, I eventually arrived at this piece of code: ``` :hw086 :hw186 :hw286 :hw386 :hw486 :hw586 :hw686 :NoHardware vecho /t %_FDNET.LANG% ERROR.HARDWARE goto End ``` and that's why it told me that Physical hardware networking is not supported at this time. Well... Not willing to admit defeat, I continued going through FDNET.BAT to find out what it was about VirtualBox and VMware that made the network go... ...and both of them branched to :vmGeneric. From THERE, I discovered that FreeDOS supports three network card families: AMD PCnet, Realtek RTL8139, and NE2000-compatibles – the same ones used by VirtualBox, VMware, and (though I haven't used FreeDOS on this) QEMU! So, going back to the physical hardware section of the batch file, I simply added a branching line after :hw686, so that the code block now reads: ``` :hw086 :hw186 :hw286 :hw386 :hw486 :hw586 :hw686 goto vmGeneric :NoHardware vecho /t %_FDNET.LANG% ERROR.HARDWARE goto End ``` and opened the 86Box configuration to install an AMD PCnet-FAST III into an emulated PCI slot, which triggered a hard reset. And wouldn't you know? The network worked! I was able to ping www.google.com and get a pong sent back to me. I'm kinda having a little bit of difficulty with fdnpkg though, so maybe there are still some kinks to work out. But for right now, I can declare at least a preliminary victory! Brandon Taylor ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: How can I get an AI Chatbot to interpret a nine page PDF?
Just sign up for Chat-GPT Plus and it’ll do it no problem. I do it all the time. From: viphone@googlegroups.com on behalf of Mario Eiland Date: Saturday, June 1, 2024 at 6:03 PM To: viphone@googlegroups.com Subject: RE: How can I get an AI Chatbot to interpret a nine page PDF? HI Keith, This might help. Here is a YouTube video tutorial for a Chrome Image to Text for ChatGPT extension. https://www.youtube.com/watch?v=zob0us4bPc8 -Original Message- From: viphone@googlegroups.com On Behalf Of Keith Kramlinger Sent: Saturday, June 1, 2024 2:40 PM To: viphone@googlegroups.com Subject: How can I get an AI Chatbot to interpret a nine page PDF? Hi, I have a nine page PDF composed of both text and images. I would like to get an AI chat bot to describe this to me. I cannot figure out how to get the complete PDF uploaded to a chatbot in order to do this. Is it possible, or just too long? I would appreciate any guidance on the viability of this, and if possible, Specific guidance on how to achieve it. Thanks in advance. Keith -- The following information is important for all members of the V iPhone list. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. Your V iPhone list moderator is Mark Taylor. Mark can be reached at: mk...@ucla.edu. Your list owner is Cara Quinn - you can reach Cara at caraqu...@caraquinn.com The archives for this list can be searched at: http://www.mail-archive.com/viphone@googlegroups.com/ --- You received this message because you are subscribed to the Google Groups "VIPhone" group. To unsubscribe from this group and stop receiving emails from it, send an email to viphone+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/viphone/DM5PR02MB3179EE6F080BC121766C6DE1DEFD2%40DM5PR02MB3179.namprd02.prod.outlook.com. -- The following information is important for all members of the V iPhone list. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. Your V iPhone list moderator is Mark Taylor. Mark can be reached at: mk...@ucla.edu. Your list owner is Cara Quinn - you can reach Cara at caraqu...@caraquinn.com The archives for this list can be searched at: http://www.mail-archive.com/viphone@googlegroups.com/ --- You received this message because you are subscribed to the Google Groups "VIPhone" group. To unsubscribe from this group and stop receiving emails from it, send an email to viphone+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/viphone/012001dab46f%24759b1c00%2460d15400%24%40gmail.com. -- The following information is important for all members of the V iPhone list. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. Your V iPhone list moderator is Mark Taylor. Mark can be reached at: mk...@ucla.edu. Your list owner is Cara Quinn - you can reach Cara at caraqu...@caraquinn.com The archives for this list can be searched at: http://www.mail-archive.com/viphone@googlegroups.com/ --- You received this message because you are subscribed to the Google Groups "VIPhone" group. To unsubscribe from this group and stop receiving emails from it, send an email to viphone+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/viphone/BYAPR13MB288855F2BED89FF411328E7DFCFD2%40BYAPR13MB2888.namprd13.prod.outlook.com.
[MariaDB developers] Re: [PATCH] MDEV-21322: Report slave progress to the master
Thanks for reviewing, Kristian! I've pushed a new commit to 11.6-MDEV-21322
which addresses
most of your findings. Anything left out I've responded to below. There
were some additional
synchronization changes that went alongside the use of LOCK_thd_data, so it
would be good if
you could go over at least the code changes again.
On Fri, May 31, 2024 at 6:02 AM Kristian Nielsen
wrote:
> Kristian Nielsen via commits writes:
>
> > From: Brandon Nesterenko
> >
> > This patch extends the command `SHOW REPLICA HOSTS` with three
> > columns:
>
> Hi Brandon, please find my review of MDEV-21322 below.
>
> > This patch extends the command `SHOW REPLICA HOSTS` with three
> > columns:
> >
> > 1) Gtid_State_Sent. This represents that latest GTIDs sent to the
> > replica in each domain. It will always be populated, regardless of
> > the semi-sync status (i.e. asynchronous connections will still
> > update this column with the latest GTID state sent to the replica).
> >
> > 2) Gtid_State_Ack. For semi-synchronous connections (only), this
> > column represents the last GTID in each domain that the replica has
> > acknowledged.
>
> Use "Pos" instead of "State", eg. Gtid_Pos_Sent and Gtid_Pos_Ack.
> To be consistent with eg. gtid_binlog_pos, which has last GTID per
> domain_id; vs. gtid_binlog_state, which has GTID per every (domain_id,
> server_id) combination.
>
> > @@ -2272,6 +2292,30 @@ send_event_to_slave(binlog_send_info *info,
> Log_event_type event_type,
> > return "Failed to run hook 'after_send_event'";
> >}
> >
> > + if (info->thd->slave_info)
> > + {
> > +strncpy(info->thd->slave_info->gtid_state_sent.log_file,
> > +info->log_file_name + info->dirlen,
> > +strlen(info->log_file_name) - info->dirlen);
> > +info->thd->slave_info->gtid_state_sent.log_pos= pos;
> > + }
>
> Isn't there missing synchronisation here against concurrent access from
> another thread?
> I guess we need LOCK_thd_data around the strncpy().
> Maybe we can avoid taking LOCK_thd_data except in the uncommon case where
> the gile name changes. It would be best to avoid a mutex lock/unlock for
> _every_ event sent to a slave.
> The position doesn't need locking I think, you can use an atomic
> std::memory_order_relaxed mostly for documentation if you like.
>
> > @@ -125,8 +114,11 @@ int THD::register_slave(uchar *packet, size_t
> packet_length)
> >if (check_access(this, PRIV_COM_REGISTER_SLAVE, any_db.str,
> NULL,NULL,0,0))
> > return 1;
> >if (!(si= (Slave_info*)my_malloc(key_memory_SLAVE_INFO,
> sizeof(Slave_info),
> > - MYF(MY_WME
> > + MYF(MY_WME|MY_ZEROFILL
> > return 1;
> > + memset(si->gtid_state_sent.log_file, '\0', FN_REFLEN);
> > + memset(si->gtid_state_ack.log_file, '\0', FN_REFLEN);
>
> I think it's good to add the MY_ZEROFILL here, but then the two memset()
> are
> redundant and can be removed.
>
> > @@ -1235,6 +1251,14 @@ int
> Repl_semi_sync_master::update_sync_header(THD* thd, unsigned char *packet,
> >*need_sync= sync;
> >
> > l_end:
> > + if (is_on())
> > + {
> > +thd->slave_info->sync_status=
> > +sync ? thd->slave_info->sync_status=
> > + Slave_info::SYNC_STATE_SEMI_SYNC_ACTIVE
> > + : thd->slave_info->sync_status=
> > + Slave_info::SYNC_STATE_SEMI_SYNC_STALE;
> > + }
>
> There's something wierd here, double assignment of
> thd->slave_info->sync_status, probably you just meant:
>
> thd->slave_info->sync_status= sync ?
> Slave_info::SYNC_STATE_SEMI_SYNC_ACTIVE :
> Slave_info::SYNC_STATE_SEMI_SYNC_STALE;
>
> More importantly, update_sync_header() is called just _before_ writing the
> event on the socket to the connected slave. Is that really the right place
> to do so? Shouldn't the status be updated only _after_ the event has been
> sent?
>
> Or does it not matter, because the actual TCP sending is asynchroneous
> anyway? In that case, should add a comment explaining why updating the
> status here is ok.
>
I don't think it matters too much, but generally, updating here seems
correct to me.
Here, it provides immediate context for the event which we are about to
send. Then
users will know that there will be an ACK, or if we are just sending events
"blindly"
until the slave catches up. Note I've put a comment into the code in my new
patch to
e
Re: BGP Confederation Internal ASN Filtering and is_bogon() Functionality in New BIRD Version
Hi Maria,
Thanks for the reply
23.172.216.0/24 unicast [I_ZJ1 10:32:48.661 from 2a13:aac7:13:7::2] *
(100) [AS398741i]
via 10.0.29.2 on CN-ZJ1
Type: BGP univ
BGP.origin: IGP
BGP.as_path: 398741 60539 60539 (65000) 60539 398741
BGP.next_hop: 10.0.29.2
BGP.med: 101
BGP.local_pref: 400
BGP.large_community: (60539, 2, 1) (60539, 6, 65000) (60539, 6,
52000)
After I enabled is_bogon() function, this route from our downstream would
be filtered.
function is_bogon() {
if is_bogon_asn() then return true;
if is_bogon_prefix() then return true;
if net_len_too_long() then return true;
return false;
}
function bgp_export()
{
# my_opt_prefix();
if is_bogon() then return false; #关闭以防止过滤bgp conf的内部ASN
if bgp_large_community ~ [(LOCAL_ASN, 4, NODE_ID)] then return false;
if is_local_prefix() then return true;
# if proto = "BGP_Prefix_play" then return true;
if source != RTS_BGP then return false;
if bgp_large_community !~ [(LOCAL_ASN, 2, 1)] then return false;
return true;
}
I always remember that in BIRD, BGP Confederation internal ASNs cannot be
counted in bgp_path.len. But BGP Confederation internal ASNs can be treated
as 'normal' ASNs for filtering?
Best,
*Brandon Zhi*
HUIZE LTD
www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter
This e-mail and any attachments or any reproduction of this e-mail in
whatever manner are confidential and for the use of the addressee(s) only.
HUIZE LTD can’t take any liability and guarantee of the text of the email
message and virus.
On Sat, 1 Jun 2024 at 22:36, Maria Matejka wrote:
> Hello Brandon,
>
> On Thu, May 30, 2024 at 09:52:53PM +0800, Brandon Zhi wrote:
>
> I am writing to inquire about the capabilities of the new version of BIRD
> regarding BGP Confederation internal ASNs. Specifically, I would like to
> know:
>
>1. Can the new BIRD version filter BGP Confederation internal ASNs?
>2. Does it support calculating the total AS path length, including
>internal ASNs within a BGP Confederation?
>
> You are probably looking for something like bgp_path.filter() or
> bgp_path.len, or maybe for int p in bgp_path do { … }
>
> Additionally, I have encountered an issue while using the is_bogon()
> function. It currently filters a route with the AS path (65000) 398741. I
> suspect this is because (65000) is being treated as a BOGON ASN.
>
> Below is the define BOGON_ASNS I am using:
>
> define BOGON_ASNS = [
> 0, # RFC 7607
> 23456, # RFC 4893 AS_TRANS
> 64496..64511, # RFC 5398 and documentation/example ASNs
> 64512..65534, # RFC 6996 Private ASNs
> 65535, # RFC 7300 Last 16 bit ASN
> 65536..65551, # RFC 5398 and documentation/example ASNs
> 65552..131071, # RFC IANA reserved ASNs
> 42..4294967294, # RFC 6996 Private ASNs
> 4294967295 # RFC 7300 Last 32 bit ASN
> ];
>
> Yes, this includes 65500. I can’t see your is_bogon() function definition
> though so I can’t help you more.
>
> Hoping that this helps.
>
> Maria
>
> – Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>
Re: [mailop] [External] Does Google not accept bounce emails anymore?
There's also nothing to prevent you from DKIM signing your bounce messages. "bounce" messages (nothing more than coming from a null sender) are often used for spam. Gmail has always applied spam rules to them. Brandon On Mon, May 27, 2024 at 4:39 PM Kevin A. McGrail via mailop < mailop@mailop.org> wrote: > Good Question. > > The RFC purist in me says, hell no. But my calmer, gentler, experience > mail inner child would say you should work to extend your edge so you > decline the message during the SMTP conversation if at all possible. > Backscatter, joe jobs, and bounces with payloads/spam have pretty much > ruined bounce messages IMO. > > Regards, > > KAM > > On 5/27/2024 7:04 PM, Jarland Donnell via mailop wrote: > > 421-4.7.26 Your email has been rate limited because it is > > unauthenticated. Gmail requires all senders to authenticate with > > either SPF or DKIM. Authentication results: DKIM = did not pass SPF [] > > with ip: [136.175.108.34] = did not pass For instructions on setting > > up authentication, go to > > https://support.google.com/mail/answer/81126#authentication > > 5614622812f47-3d1b370fc69si2809030b6e.141 - gsmtp > > > > Bounces coming from blank envelope senders are being held to SPF/DKIM > > authentication, which of course fails. Been seeing this a lot lately. > > Should we just not send bounce emails to Google anymore? > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [DISCUSS] Stream Pipelines on hot paths
On Fri, May 31, 2024 at 9:35 AM Abe Ratnofsky wrote: > +1 to forbidding Stream usage entirely; the convenience of using them > outside of hot paths is less than the burden of figuring out whether or not > a particular path is hot. > I think I have most frequently appreciated them in tests, which I think we could except, since these are categorically not in the hot path. Kind Regards, Brandon
[jira] [Updated] (CASSANDRA-19672) some unit tests should generate files in the tmp directory
[
https://issues.apache.org/jira/browse/CASSANDRA-19672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19672:
-
Fix Version/s: 5.x
(was: 5.1)
> some unit tests should generate files in the tmp directory
> --
>
> Key: CASSANDRA-19672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19672
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Ling Mao
>Assignee: Ling Mao
>Priority: Normal
> Fix For: 5.x
>
>
> I run "{*}_ant test_{*}" to fire the whole test suit cases in my local
> machine, and found some UTs had generated files in current directory,
> otherwise the tmp directory.
>
> {code:java}
> [root@vm-24-5-centos cassandra]# git status
> # audit/
> # compaction.log
> #
> import_cql_test_keyspace_table_testcopyonlythoserowsthatmatchvectortyp_04.err
> {code}
>
> These problematic UTs are
>
> {code:java}
> ant testsome
> -Dtest.name=org.apache.cassandra.service.StorageServiceServerTest
> -Dtest.methods=testAuditLogEnableLoggerNotFound
> ant testsome
> -Dtest.name=org.apache.cassandra.service.StorageServiceServerTest
> -Dtest.methods=testAuditLogEnableLoggerTransitions
> ant testsome -Dtest.name=org.apache.cassandra.tools.CompactionStressTest
> -Dtest.methods=testWriteAndCompact
> ant testsome -Dtest.name=org.apache.cassandra.tools.cqlsh.CqlshTest
> -Dtest.methods=testCopyOnlyThoseRowsThatMatchVectorTypeSize
> {code}
>
> The patch is aimed to generate files in the tmp directory to fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
BGP Confederation Internal ASN Filtering and is_bogon() Functionality in New BIRD Version
Hi there, I am writing to inquire about the capabilities of the new version of BIRD regarding BGP Confederation internal ASNs. Specifically, I would like to know: 1. Can the new BIRD version filter BGP Confederation internal ASNs? 2. Does it support calculating the total AS path length, including internal ASNs within a BGP Confederation? Additionally, I have encountered an issue while using the `is_bogon()` function. It currently filters a route with the AS path (65000) 398741. I suspect this is because (65000) is being treated as a BOGON ASN. Below is the `define BOGON_ASNS` I am using: ```plaintext define BOGON_ASNS = [ 0, # RFC 7607 23456, # RFC 4893 AS_TRANS 64496..64511, # RFC 5398 and documentation/example ASNs 64512..65534, # RFC 6996 Private ASNs 65535, # RFC 7300 Last 16 bit ASN 65536..65551, # RFC 5398 and documentation/example ASNs 65552..131071, # RFC IANA reserved ASNs 42..4294967294, # RFC 6996 Private ASNs 4294967295 # RFC 7300 Last 32 bit ASN ]; ``` Best regards, *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850143#comment-17850143
]
Brandon Williams commented on CASSANDRA-17667:
--
I converted it to pytest in CASSANDRA-18088,
[here|https://github.com/driftx/cassandra/commit/62c94ccf4cb2432fde954bf4c12db1325b3a62a1].
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850139#comment-17850139
]
Brandon Williams commented on CASSANDRA-17667:
--
bq. 4.0.x uses nosetests
Can you show me where?
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19663) trunk fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849392#comment-17849392
]
Brandon Williams commented on CASSANDRA-19663:
--
Try removing the ~/.m2 directory if it has one, since that is outside of what
is cloned.
> trunk fails to start
>
>
> Key: CASSANDRA-19663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19663
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jon Haddad
>Priority: Normal
>
> On commit {{6701259bce91672a7c3ca9fb77ea7b040e9c}}, I get errors on
> startup.
> Verified the build was successful:
> {noformat}
> easy-cass-lab.amazon-ebs.ubuntu: BUILD SUCCESSFUL
> easy-cass-lab.amazon-ebs.ubuntu: Total time: 1 minute 41 seconds
> {noformat}
> Running on a new Ubuntu instance:
> {noformat}
> INFO [main] 2024-05-24 18:31:16,397 YamlConfigurationLoader.java:103 -
> Configuration location: file:/usr/local/cassandra/trunk/conf/cassandra.yaml
> ERROR [main] 2024-05-24 18:31:16,470 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.NoSuchMethodError: 'void
> org.yaml.snakeyaml.LoaderOptions.setCodePointLimit(int)'
> at
> org.apache.cassandra.config.YamlConfigurationLoader.getDefaultLoaderOptions(YamlConfigurationLoader.java:433)
> at
> org.apache.cassandra.config.YamlConfigurationLoader$CustomConstructor.(YamlConfigurationLoader.java:278)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:135)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:116)
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:403)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:265)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:250)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:781)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:724)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
> {noformat}
> Running on Java 17:
> {noformat}
> ubuntu@cassandra0:~$ java -version
> openjdk version "17.0.10" 2024-01-16
> OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
> OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode,
> sharing)
> {noformat}
> Built with 11.
> The only configs I changed:
> {noformat}
> cluster_name: "system_views"
> num_tokens: 4
> seed_provider:
> class_name: "org.apache.cassandra.locator.SimpleSeedProvider"
> parameters:
> seeds: "10.0.0.225"
> hints_directory: "/mnt/cassandra/hints"
> data_file_directories:
> - "/mnt/cassandra/data"
> commitlog_directory: "/mnt/cassandra/commitlog"
> concurrent_reads: 64
> concurrent_writes: 64
> trickle_fsync: true
> endpoint_snitch: "Ec2Snitch"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19663) trunk fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849378#comment-17849378
]
Brandon Williams commented on CASSANDRA-19663:
--
This looks like some kind of build problem and doesn't repro for me, maybe try
a realclean?
> trunk fails to start
>
>
> Key: CASSANDRA-19663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19663
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jon Haddad
>Priority: Normal
>
> On commit {{6701259bce91672a7c3ca9fb77ea7b040e9c}}, I get errors on
> startup.
> Verified the build was successful:
> {noformat}
> easy-cass-lab.amazon-ebs.ubuntu: BUILD SUCCESSFUL
> easy-cass-lab.amazon-ebs.ubuntu: Total time: 1 minute 41 seconds
> {noformat}
> Running on a new Ubuntu instance:
> {noformat}
> INFO [main] 2024-05-24 18:31:16,397 YamlConfigurationLoader.java:103 -
> Configuration location: file:/usr/local/cassandra/trunk/conf/cassandra.yaml
> ERROR [main] 2024-05-24 18:31:16,470 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.NoSuchMethodError: 'void
> org.yaml.snakeyaml.LoaderOptions.setCodePointLimit(int)'
> at
> org.apache.cassandra.config.YamlConfigurationLoader.getDefaultLoaderOptions(YamlConfigurationLoader.java:433)
> at
> org.apache.cassandra.config.YamlConfigurationLoader$CustomConstructor.(YamlConfigurationLoader.java:278)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:135)
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:116)
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:403)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:265)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:250)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:781)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:724)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
> {noformat}
> Running on Java 17:
> {noformat}
> ubuntu@cassandra0:~$ java -version
> openjdk version "17.0.10" 2024-01-16
> OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
> OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode,
> sharing)
> {noformat}
> Built with 11.
> The only configs I changed:
> {noformat}
> cluster_name: "system_views"
> num_tokens: 4
> seed_provider:
> class_name: "org.apache.cassandra.locator.SimpleSeedProvider"
> parameters:
> seeds: "10.0.0.225"
> hints_directory: "/mnt/cassandra/hints"
> data_file_directories:
> - "/mnt/cassandra/data"
> commitlog_directory: "/mnt/cassandra/commitlog"
> concurrent_reads: 64
> concurrent_writes: 64
> trickle_fsync: true
> endpoint_snitch: "Ec2Snitch"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19241) Upgrade ci-cassandra.a.o agents to Ubuntu 22.04.3
[ https://issues.apache.org/jira/browse/CASSANDRA-19241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849375#comment-17849375 ] Brandon Williams commented on CASSANDRA-19241: -- 41 and 42 in INFRA-25820. It looks like 43 may need to be replaced like 39 was. > Upgrade ci-cassandra.a.o agents to Ubuntu 22.04.3 > - > > Key: CASSANDRA-19241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19241 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Michael Semb Wever >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > All agents are currently Ubuntu 18.04 LTS per the > [docs|https://github.com/apache/cassandra-builds/blob/trunk/ASF-jenkins-agents.md#server-requirements]. > All agents need to be upgraded to Ubuntu 22.04.3 LTS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17667) Text value containing "/*" interpreted as multiline comment in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849368#comment-17849368
]
Brandon Williams commented on CASSANDRA-17667:
--
That looks good to me [~bschoeni] if you want to prepare the branches.
> Text value containing "/*" interpreted as multiline comment in cqlsh
>
>
> Key: CASSANDRA-17667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17667
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ANOOP THOMAS
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> I use CQLSH command line utility to load some DDLs. The version of utility I
> use is this:
> {noformat}
> [cqlsh 6.0.0 | Cassandra 4.0.0.47 | CQL spec 3.4.5 | Native protocol
> v5]{noformat}
> Command that loads DDL.cql:
> {noformat}
> cqlsh -u username -p password cassandra.example.com 65503 --ssl -f DDL.cql
> {noformat}
> I have a line in CQL script that breaks the syntax.
> {noformat}
> INSERT into tablename (key,columnname1,columnname2) VALUES
> ('keyName','value1','/value2/*/value3');{noformat}
> {{/*}} here is interpreted as start of multi-line comment. It used to work on
> older versions of cqlsh. The error I see looks like this:
> {noformat}
> SyntaxException: line 4:2 mismatched input 'Update' expecting ')'
> (...,'value1','/value2INSERT into tablename(INSERT into tablename
> (key,columnname1,columnname2)) VALUES ('[Update]-...) SyntaxException: line
> 1:0 no viable alternative at input '(' ([(]...)
> {noformat}
> Same behavior while running in interactive mode too. {{/*}} inside a CQL
> statement should not be interpreted as start of multi-line comment.
> With schema:
> {code:java}
> CREATE TABLE tablename ( key text primary key, columnname1 text, columnname2
> text);{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19661) Cannot restart Cassandra 5 after creating a vector table and index
[
https://issues.apache.org/jira/browse/CASSANDRA-19661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19661:
-
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
Complexity: Normal
Component/s: Feature/SAI
Discovered By: User Report
Fix Version/s: 5.0-rc
5.x
Severity: Normal
Status: Open (was: Triage Needed)
The schema alone is not enough to reproduce, but it looks like this should
block 5.0-rc.
> Cannot restart Cassandra 5 after creating a vector table and index
> --
>
> Key: CASSANDRA-19661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19661
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Sergio Rua
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> I'm using llama-index and llama3 to train a model. I'm using a very simple
> code that reads some *.txt files from local and uploads them to Cassandra and
> then creates the index:
>
> {code:java}
> # Create the index from documents
> index = VectorStoreIndex.from_documents(
> documents,
> service_context=vector_store.service_context,
> storage_context=storage_context,
> show_progress=True,
> ) {code}
> This works well and I'm able to use a Chat app to get responses from the
> Cassandra data. however, right after, I cannot restart Cassandra. It'll break
> with the following error:
>
> {code:java}
> INFO [PerDiskMemtableFlushWriter_0:7] 2024-05-23 08:23:20,102
> Flushing.java:179 - Completed flushing
> /data/cassandra/data/gpt/docs_20240523-10c8eaa018d811ef8dadf75182f3e2b4/da-6-bti-Data.db
> (124.236MiB) for commitlog position
> CommitLogPosition(segmentId=1716452305636, position=15336)
> [...]
> WARN [MemtableFlushWriter:1] 2024-05-23 08:28:29,575
> MemtableIndexWriter.java:92 - [gpt.docs.idx_vector_docs] Aborting index
> memtable flush for
> /data/cassandra/data/gpt/docs-aea77a80184b11ef8dadf75182f3e2b4/da-3-bti...{code}
> {code:java}
> java.lang.IllegalStateException: null
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:496)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.VectorPostings.computeRowIds(VectorPostings.java:76)
> at
> org.apache.cassandra.index.sai.disk.v1.vector.OnHeapGraph.writeData(OnHeapGraph.java:313)
> at
> org.apache.cassandra.index.sai.memory.VectorMemoryIndex.writeDirect(VectorMemoryIndex.java:272)
> at
> org.apache.cassandra.index.sai.memory.MemtableIndex.writeDirect(MemtableIndex.java:110)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flushVectorIndex(MemtableIndexWriter.java:192)
> at
> org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:117)
> at
> org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
> at
> org.apache.cassandra.db.compaction.unified.ShardedMultiWriter.commit(ShardedMultiWriter.java:219)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1323)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1222)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
> The table created by the script is as follows:
>
> {noformat}
> CREATE TABLE gpt.docs (
> partition_id text,
> row_id text,
> attributes_blob text,
> body_blob text,
> vector vector,
> metadata_s map,
> PRIMARY KEY (partition_id, row_id)
> ) WITH CLUSTERING ORDER BY (row_id ASC)
> AND additional_write_policy = '99p'
> AND allow_auto_snapshot = true
> AND bloom_filter_fp_chance = 0.01
> AND ca
Re: Updating Instaclustr donated Jenkins Agents
On Fri, May 24, 2024 at 9:07 AM Brandon Williams wrote: > I just want to note that this will reduce the x86 pool from 42 to 31, Or more correctly, the pool will go from 42 to 33 x86 agents. Kind Regards, Brandon
Re: Updating Instaclustr donated Jenkins Agents
On Thu, May 23, 2024 at 5:51 PM Fleming, Jackson via dev wrote: > Primarily this would be moving from x86 instances to Graviton ARM based ones, > as we’ve seen a pretty good uptake of ARM usage, and we’d like to help ensure > that there’s good testing coverage across both x86 and ARM architectures. I just want to note that this will reduce the x86 pool from 42 to 31, and then we will have a parallel pipeline of 9 ARM agents (15 if the other 6 come back.) Currently I think we have about an 8 hour post-commit run time with 42 machines (though I'm sure there is room for improvement.) Also I'm going to update the agents page you linked shortly, but in CASSANDRA-19241 we are upgrading all hosts to Ubuntu 22.04 and using one single large partition for everything, so if you switch them please keep that in mind. Kind Regards, Brandon
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849305#comment-17849305 ] Brandon Williams commented on CASSANDRA-19632: -- The auth failure looks like CASSANDRA-19217 and durable writes is CASSANDRA-19601. +1 > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19217: - Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19217) Test failure: auth_test.TestAuthUnavailable
[ https://issues.apache.org/jira/browse/CASSANDRA-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849304#comment-17849304 ] Brandon Williams commented on CASSANDRA-19217: -- Also here: https://app.circleci.com/pipelines/github/instaclustr/cassandra/4344/workflows/f9410f3a-9af4-4924-a2c8-44fc3d7384c0/jobs/237001/tests > Test failure: auth_test.TestAuthUnavailable > --- > > Key: CASSANDRA-19217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19217 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Jacek Lewandowski >Priority: Normal > Fix For: 5.x > > > https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1233/workflows/bb617340-f1da-4550-9c87-5541469972c4/jobs/62551/tests -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19654) Update bundled Cassandra cassandra-driver-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-19654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849268#comment-17849268 ] Brandon Williams commented on CASSANDRA-19654: -- We're already [suppressing|https://github.com/apache/cassandra/blob/trunk/.build/owasp/dependency-check-suppressions.xml] some jackson-databind and netty CVEs, if this isn't tripping OWASP then I'm not sure it's a problem. > Update bundled Cassandra cassandra-driver-core dependency > - > > Key: CASSANDRA-19654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19654 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Jackson Fleming >Priority: Normal > > There's a dependency in Cassandra project on an old version of the Java > driver cassandra-driver-core - 3.11.0 in the 4.0 and later releases of > Cassandra > > (For example on the 4.1 branch > [https://github.com/apache/cassandra/blob/cassandra-4.1/build.xml#L691)] > > It appears that this dependency may have some security vulnerabilities in > transitive dependencies. > But also this is a very old version of the driver, ideally it would be > aligned to a newer version, I would suggest either 3.11.5 which is the latest > in that line of driver versions > [https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core|https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core)] > or this gets updated to the latest 4.x driver (as of writing that's 4.18.1 in > [https://mvnrepository.com/artifact/org.apache.cassandra/java-driver-core] ) > but this seems like a larger undertaking. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19632: - Reviewers: Brandon Williams Status: Review In Progress (was: Needs Committer) > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
[
https://issues.apache.org/jira/browse/CASSANDRA-19658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> Test failure:
> replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
> --
>
> Key: CASSANDRA-19658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19658
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> This can be seen failing in butler:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-5.0/failure/replace_address_test/TestReplaceAddress/test_restart_failed_replace
> {noformat}
> ccmlib.node.TimeoutError: 14 May 2024 18:19:08 [node1] after 120.13/120
> seconds Missing: ['FatClient /127.0.0.4:7000 has been silent for 3ms,
> removing from gossip'] not found in system.log:
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
[
https://issues.apache.org/jira/browse/CASSANDRA-19658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849089#comment-17849089
]
Brandon Williams commented on CASSANDRA-19658:
--
bq. Looks like fallout from CASSANDRA-15439
Indeed it was, patch
[here|https://github.com/driftx/cassandra-dtest/commit/b6a87433bfb37a00fe195fb838581864d66dee35]
to set the timeout to match the test.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-4.0]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1646/workflows/1d6dccad-7313-43f9-83a6-8fad2d592a38]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-4.1]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1647/workflows/944ecc10-0573-4c64-a180-db4006db30b1]|
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-5.0]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1648/workflows/2b5d5e3f-614a-4f02-b43c-b3efd345d2f1]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19658-trunk]|[repeats|https://app.circleci.com/pipelines/github/driftx/cassandra/1649/workflows/01e57f68-f196-4986-b51c-2e90c4e1058a]|
> Test failure:
> replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
> --
>
> Key: CASSANDRA-19658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19658
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> This can be seen failing in butler:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-5.0/failure/replace_address_test/TestReplaceAddress/test_restart_failed_replace
> {noformat}
> ccmlib.node.TimeoutError: 14 May 2024 18:19:08 [node1] after 120.13/120
> seconds Missing: ['FatClient /127.0.0.4:7000 has been silent for 3ms,
> removing from gossip'] not found in system.log:
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [VOTE] Release Apache Cassandra Java Driver 4.18.1 (2nd attempt)
+1 Kind Regards, Brandon On Tue, May 21, 2024 at 5:59 PM Bret McGuire wrote: > >Greetings all! We're going to give this another go. > >Apologies for the confusion that sprang out of our last attempt. It > appears that the Nexus staging repository for the 4.18.1 release was > accidentally released shortly after it was created. As a result Maven > artifacts for this release are already out in the wild, so this vote will be > a little unusual. We'll be voting normally, but if the vote is successful > we'll simply leave the Maven artifacts exactly where they are. If the vote > is unsuccessful these artifacts will be removed from Maven Central and we'll > try again with 4.18.2. > >Big thanks to mck and driftx for their help in untangling these issues. > >With all of that said let's get to it. I’m proposing the test build of > Cassandra Java Driver 4.18.1 for release. > > sha1: cbdde2878786fa6c4077a21352cbe738875f2106 > > Git: https://github.com/apache/cassandra-java-driver/tree/4.18.1 > > Maven Artifacts: As discussed above > > >The Source release and Binary convenience artifacts are available here: > > https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver/4.18.1/ > > >The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1's. > >One additional note: this is my first time doing a release of the Java > driver so if you're so inclined you can find my PGP key information in the > KEYS file. > > >Thanks all! > > >- Bret -
[jira] [Commented] (CASSANDRA-19660) Support for netty-tcnative 2.0.62+
[ https://issues.apache.org/jira/browse/CASSANDRA-19660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849002#comment-17849002 ] Brandon Williams commented on CASSANDRA-19660: -- 2.0.62 for trunk sounds reasonable to me. > Support for netty-tcnative 2.0.62+ > -- > > Key: CASSANDRA-19660 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19660 > Project: Cassandra > Issue Type: Improvement >Reporter: Zbyszek Z >Priority: Normal > > Hello, > Are there plans to support netty-tcnative in version 2.0.62? Current version > 2.0.36 does not work with openssl3.x. Motivation is that openssl 3.0.9+ is > FIPS certified. > Currently i am able to replace library default boringSSL implementation with > openssl by recompiling netty-tcnative but cassandra fails to load 2.0.62 > regardless if it is compiled with 1.1.1 or 3.0. > Or is there other way to implement openssl3.x ? > Thank you -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19660) Support for netty-tcnative 2.0.62+
[ https://issues.apache.org/jira/browse/CASSANDRA-19660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848982#comment-17848982 ] Brandon Williams commented on CASSANDRA-19660: -- Trunk is already at 2.0.61: https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml#L802 We won't be upgrading libs in released majors (including 5.0 at this point since it is so close.) > Support for netty-tcnative 2.0.62+ > -- > > Key: CASSANDRA-19660 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19660 > Project: Cassandra > Issue Type: Improvement >Reporter: Zbyszek Z >Priority: Normal > > Hello, > Are there plans to support netty-tcnative in version 2.0.62? Current version > 2.0.36 does not work with openssl3.x. Motivation is that openssl 3.0.9+ is > FIPS certified. > Currently i am able to replace library default boringSSL implementation with > openssl by recompiling netty-tcnative but cassandra fails to load 2.0.62 > regardless if it is compiled with 1.1.1 or 3.0. > Or is there other way to implement openssl3.x ? > Thank you -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
[
https://issues.apache.org/jira/browse/CASSANDRA-19658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848784#comment-17848784
]
Brandon Williams commented on CASSANDRA-19658:
--
Looks like fallout from CASSANDRA-15439
> Test failure:
> replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
> --
>
> Key: CASSANDRA-19658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19658
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> This can be seen failing in butler:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-5.0/failure/replace_address_test/TestReplaceAddress/test_restart_failed_replace
> {noformat}
> ccmlib.node.TimeoutError: 14 May 2024 18:19:08 [node1] after 120.13/120
> seconds Missing: ['FatClient /127.0.0.4:7000 has been silent for 3ms,
> removing from gossip'] not found in system.log:
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
[
https://issues.apache.org/jira/browse/CASSANDRA-19658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Fix Version/s: 5.0.x
(was: 5.0-rc)
> Test failure:
> replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
> --
>
> Key: CASSANDRA-19658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19658
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> This can be seen failing in butler:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-5.0/failure/replace_address_test/TestReplaceAddress/test_restart_failed_replace
> {noformat}
> ccmlib.node.TimeoutError: 14 May 2024 18:19:08 [node1] after 120.13/120
> seconds Missing: ['FatClient /127.0.0.4:7000 has been silent for 3ms,
> removing from gossip'] not found in system.log:
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
[
https://issues.apache.org/jira/browse/CASSANDRA-19658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19658:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Cluster/Membership
Discovered By: DTest
Fix Version/s: 4.0.x
4.1.x
5.0-rc
Severity: Normal
Status: Open (was: Triage Needed)
> Test failure:
> replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
> --
>
> Key: CASSANDRA-19658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19658
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0-rc
>
>
> This can be seen failing in butler:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-5.0/failure/replace_address_test/TestReplaceAddress/test_restart_failed_replace
> {noformat}
> ccmlib.node.TimeoutError: 14 May 2024 18:19:08 [node1] after 120.13/120
> seconds Missing: ['FatClient /127.0.0.4:7000 has been silent for 3ms,
> removing from gossip'] not found in system.log:
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
[
https://issues.apache.org/jira/browse/CASSANDRA-19658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-19658:
Assignee: Brandon Williams
> Test failure:
> replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
> --
>
> Key: CASSANDRA-19658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19658
> Project: Cassandra
> Issue Type: Bug
> Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> This can be seen failing in butler:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-5.0/failure/replace_address_test/TestReplaceAddress/test_restart_failed_replace
> {noformat}
> ccmlib.node.TimeoutError: 14 May 2024 18:19:08 [node1] after 120.13/120
> seconds Missing: ['FatClient /127.0.0.4:7000 has been silent for 3ms,
> removing from gossip'] not found in system.log:
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19658) Test failure: replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
Brandon Williams created CASSANDRA-19658:
Summary: Test failure:
replace_address_test.py::TestReplaceAddress::test_restart_failed_replace
Key: CASSANDRA-19658
URL: https://issues.apache.org/jira/browse/CASSANDRA-19658
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
This can be seen failing in butler:
https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-5.0/failure/replace_address_test/TestReplaceAddress/test_restart_failed_replace
{noformat}
ccmlib.node.TimeoutError: 14 May 2024 18:19:08 [node1] after 120.13/120 seconds
Missing: ['FatClient /127.0.0.4:7000 has been silent for 3ms, removing from
gossip'] not found in system.log:
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19648: - Fix Version/s: 5.1 > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.1-alpha1, 5.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19656) Revisit disabling chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-19656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19656: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Revisit disabling chronicle analytics > - > > Key: CASSANDRA-19656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19656 > Project: Cassandra > Issue Type: Task > Components: Local/Other > Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0.x, 5.x > > > We first considered this in CASSANDRA-18538 but determined it wasn't a > problem. We have upgraded chronicle in CASSANDRA-18049 so we should > reconfirm with packet analysis that nothing is phoning home, and perhaps > consider taking further precautions by proactively disabling it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19656) Revisit disabling chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-19656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848742#comment-17848742 ] Brandon Williams commented on CASSANDRA-19656: -- bq. Would be supportive of revisiting alternate libs in a future major to avoid the need to explicitly disable as well. I am in agreement there, it would be best to not have to do this again. For now, I have again confirmed nothing is phoning home while capturing packets during manual tests, unit tests, in-jvm dtests, and the fql and auditlog python dtests. [Here|https://github.com/driftx/cassandra/tree/CASSANDRA-19656-5.0] is a branch that revives my patch from CASSANDRA-18538 to disable in the server options, and takes [~aweisberg]'s suggestion of also disabling in static init in DatabaseDescriptor. If that looks agreeable I will merge up and run CI. > Revisit disabling chronicle analytics > - > > Key: CASSANDRA-19656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19656 > Project: Cassandra > Issue Type: Task > Components: Local/Other > Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0.x, 5.x > > > We first considered this in CASSANDRA-18538 but determined it wasn't a > problem. We have upgraded chronicle in CASSANDRA-18049 so we should > reconfirm with packet analysis that nothing is phoning home, and perhaps > consider taking further precautions by proactively disabling it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: China internet issues
One of the issues in China is the existence of the Great Firewall. Its impact is not only about blocking access, but also throttling non-mainland traffic during peak hours, such as in the evenings, through QoS restrictions. Additionally, similar to most Asian home ISPs, Chinese ISPs are not inclined to optimize international routing. Usually, all non-mainland traffic is routed through the United States or European countries instead of connecting directly. Even for traffic to Hong Kong, if there is no paid peering agreement, the traffic from China Telecom's home broadband users will be routed through the United States before reaching Hong Kong. Basically means you have to pay the 3 largest ISPs in China to have a better performance for users in China Mainland. *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Wed, 22 May 2024 at 10:40, Mirai Azayaka wrote: > Hey, what kind of issue are you looking at? The three major ISPs are > China Telecom, China Unicom, and China Mobile. However, most issues > are probably related to the Great Firewall (GFW). It can do many > different things (DNS poisoning, IP blackhole, IP:port block, TCP > reset, etc.) on the state level. > > On Wed, May 22, 2024 at 10:24 AM Vinod Ola > wrote: > > > > Yes but it has very old posts. Doesn’t look active anymore. > > > > We are having outlook disconnections since 2 weeks and Chinese ISP > doesn’t tell what’s going on. > > > > Sent from my iPhone > > > > > On 22 May 2024, at 9:19 PM, Stephane Bortzmeyer > wrote: > > > > > > On Wed, May 22, 2024 at 08:18:05PM +0530, > > > Vinod Ola wrote > > > a message of 139 lines which said: > > > > > >> Can anyone please help me to get view of China ISP issues and > backbone issues? > > > > > > There is a chinese network operators group (found from > > > <https://labs.ripe.net/nogs/>) > > > but it seems without any real activity: > > > > > > https://groups.google.com/g/cnnog >
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848634#comment-17848634 ] Brandon Williams commented on CASSANDRA-19632: -- I think we should check some microbenchmarks around this. My understanding is the trace function will call isTraceEnabled itself, so wrapping this purely for trace logging calls shouldn't be beneficial, only if the flag is used to prevent other execution from occurring. > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19656) Revisit disabling chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-19656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19656: - Change Category: Quality Assurance Complexity: Normal Component/s: Local/Other Fix Version/s: 5.0.x 5.x Assignee: Brandon Williams Status: Open (was: Triage Needed) > Revisit disabling chronicle analytics > - > > Key: CASSANDRA-19656 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19656 > Project: Cassandra > Issue Type: Task > Components: Local/Other > Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0.x, 5.x > > > We first considered this in CASSANDRA-18538 but determined it wasn't a > problem. We have upgraded chronicle in CASSANDRA-18049 so we should > reconfirm with packet analysis that nothing is phoning home, and perhaps > consider taking further precautions by proactively disabling it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19656) Revisit disabling chronicle analytics
Brandon Williams created CASSANDRA-19656: Summary: Revisit disabling chronicle analytics Key: CASSANDRA-19656 URL: https://issues.apache.org/jira/browse/CASSANDRA-19656 Project: Cassandra Issue Type: Task Reporter: Brandon Williams We first considered this in CASSANDRA-18538 but determined it wasn't a problem. We have upgraded chronicle in CASSANDRA-18049 so we should reconfirm with packet analysis that nothing is phoning home, and perhaps consider taking further precautions by proactively disabling it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[Sprinklerforum] Re: Interstitial Heads
Since NFPA 13 (2002 edition) was published the sprinkler selected for protection of concealed combustible spaces less than 36” shall be listed for such use. An upright is not listed for that application. Thank you. Brandon Telford Sent from my iPhone. On Wed, May 22, 2024 at 8:37 AM Brian Harris wrote: > Is there a benefit, and or requirement, to use Interstitial heads instead > of a plane jane 5.6k upright in those spaces? > > > > Thank you, > > > > *Brian Harris, CET* > > BVS Systems Inc. > > bvssystemsinc.com > > Phone: 704.896.9989 > > Fax: 704.896.1935 > > > > _ > SprinklerForum mailing list: > https://lists.firesprinkler.org/list/sprinklerforum.lists.firesprinkler.org > To unsubscribe send an email to > sprinklerforum-le...@lists.firesprinkler.org _ SprinklerForum mailing list: https://lists.firesprinkler.org/list/sprinklerforum.lists.firesprinkler.org To unsubscribe send an email to sprinklerforum-le...@lists.firesprinkler.org
[jira] [Updated] (CASSANDRA-19652) ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader buffer
[ https://issues.apache.org/jira/browse/CASSANDRA-19652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19652: - Change Category: Performance Complexity: Normal Status: Open (was: Triage Needed) > ShallowInfoRetriever: cache offsets to void resetting of RandomAccessReader > buffer > -- > > Key: CASSANDRA-19652 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19652 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Dmitry Konstantinov >Assignee: Dmitry Konstantinov >Priority: Normal > Fix For: 5.x > > > Currently in > org.apache.cassandra.io.sstable.format.big.RowIndexEntry.ShallowInfoRetriever#fetchIndex > we do 2 seek/read operations: 1st is to find the offset for IndexInfo and > the 2nd to read it. These are two quite distant regions of the file and for > standard disk access mode we do not use a benefit from a buffer in > RandomAccessReader due to jumping between the regions and reseting this > buffer again and again. A possible improvement here can be to read and cache > N first offsets (to limit the amount of memory to use) on the first read and > do later only sequential reads of IndexInfo data. By caching of less than 1Kb > we can reduce the number of syscalls even more, in my case: from few hundred > to less than 10. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19651:
-
Fix Version/s: 5.0.x
5.x
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19651:
-
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: Legacy/Observability
Severity: Normal
Status: Open (was: Triage Needed)
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: voiceOver acting strangely with menus on sonoma
Ah, you’re a life-saver—that did it! From: macvisionaries@googlegroups.com on behalf of Ian Robinson Date: Tuesday, May 21, 2024 at 10:26 AM To: 'Donna Goodin' via MacVisionaries Subject: Re: voiceOver acting strangely with menus on sonoma Hi Brandon, Open the VoiceOver Utility and select the Navigation category. Then check that Mouse Pointer is set to "Ignores VoiceOver cursor”. HTH. Ian > On 21 May 2024, at 13:25, Brandon Olivares wrote: > > I recently upgraded to Sonoma, and voiceOver is acting strangely with menus. > I can no longer navigate to a specific menu with a single letter. For > instance, in Safari I used to be able to press VO-M, then B to get to > bookmarks. Now it seems to drop down the first menu by default. > Also, sometimes in Safari it just exits out of the menu randomly. I have a > bookmark buried inside a subfolder and sometimes I can’t get to it before it > exits the menu entirely. > Is anyone else having this issue? I’m not super impressed with VoiceOver on > Sonoma. > Thanks, > Brandon > > -- > The following information is important for all members of the Mac Visionaries > list. > > If you have any questions or concerns about the running of this list, or if > you feel that a member's post is inappropriate, please contact the owners or > moderators directly rather than posting on the list itself. > > Your Mac Visionaries list moderator is Mark Taylor. You can reach mark at: > mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at > caraqu...@caraquinn.com > > The archives for this list can be searched at: > http://www.mail-archive.com/macvisionaries@googlegroups.com/ > --- > You received this message because you are subscribed to the Google Groups > "MacVisionaries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to macvisionaries+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/macvisionaries/MN2PR13MB4053E2759C3ED1CF2985DE87F0EA2%40MN2PR13MB4053.namprd13.prod.outlook.com. -- The following information is important for all members of the Mac Visionaries list. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. Your Mac Visionaries list moderator is Mark Taylor. You can reach mark at: mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at caraqu...@caraquinn.com The archives for this list can be searched at: http://www.mail-archive.com/macvisionaries@googlegroups.com/ --- You received this message because you are subscribed to the Google Groups "MacVisionaries" group. To unsubscribe from this group and stop receiving emails from it, send an email to macvisionaries+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/macvisionaries/E944F9BE-117D-47A5-90B5-E184895B3A24%40hotmail.co.uk. -- The following information is important for all members of the Mac Visionaries list. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. Your Mac Visionaries list moderator is Mark Taylor. You can reach mark at: mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at caraqu...@caraquinn.com The archives for this list can be searched at: http://www.mail-archive.com/macvisionaries@googlegroups.com/ --- You received this message because you are subscribed to the Google Groups "MacVisionaries" group. To unsubscribe from this group and stop receiving emails from it, send an email to macvisionaries+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/macvisionaries/MN2PR13MB4053FB88C3014D5C83991E8EF0EA2%40MN2PR13MB4053.namprd13.prod.outlook.com.
[jira] [Updated] (CASSANDRA-19651) idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied
[
https://issues.apache.org/jira/browse/CASSANDRA-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19651:
-
Fix Version/s: 4.1.x
> idealCLWriteLatency metric reports the worst response time instead of the
> time when ideal CL is satisfied
> -
>
> Key: CASSANDRA-19651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19651
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dmitry Konstantinov
>Priority: Normal
> Fix For: 4.1.x
>
>
> {code:java}
> private final void decrementResponseOrExpired()
> {
> int decrementedValue = responsesAndExpirations.decrementAndGet();
> if (decrementedValue == 0)
> {
> // The condition being signaled is a valid proxy for the CL being
> achieved
> // Only mark it as failed if the requested CL was achieved.
> if (!condition.isSignalled() && requestedCLAchieved)
> {
> replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
> }
> else
> {
>
> replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() -
> queryStartNanoTime);
> }
> }
> } {code}
> Actual result: responsesAndExpirations is a total number of replicas across
> all DCs which does not depend on the ideal CL, so the metric value for
> replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the
> latest response/timeout for all replicas.
> Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated
> when we get enough responses from replicas according to the ideal CL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
voiceOver acting strangely with menus on sonoma
I recently upgraded to Sonoma, and voiceOver is acting strangely with menus. I can no longer navigate to a specific menu with a single letter. For instance, in Safari I used to be able to press VO-M, then B to get to bookmarks. Now it seems to drop down the first menu by default. Also, sometimes in Safari it just exits out of the menu randomly. I have a bookmark buried inside a subfolder and sometimes I can’t get to it before it exits the menu entirely. Is anyone else having this issue? I’m not super impressed with VoiceOver on Sonoma. Thanks, Brandon -- The following information is important for all members of the Mac Visionaries list. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. Your Mac Visionaries list moderator is Mark Taylor. You can reach mark at: mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at caraqu...@caraquinn.com The archives for this list can be searched at: http://www.mail-archive.com/macvisionaries@googlegroups.com/ --- You received this message because you are subscribed to the Google Groups "MacVisionaries" group. To unsubscribe from this group and stop receiving emails from it, send an email to macvisionaries+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/macvisionaries/MN2PR13MB4053E2759C3ED1CF2985DE87F0EA2%40MN2PR13MB4053.namprd13.prod.outlook.com.
[clang] [llvm] [RISCV] Bump Zaamo and Zalrsc to version 1.0 (PR #91556)
https://github.com/4vtomat closed https://github.com/llvm/llvm-project/pull/91556 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Bump Zaamo and Zalrsc to version 1.0 (PR #91556)
https://github.com/4vtomat updated
https://github.com/llvm/llvm-project/pull/91556
>From 062d7d5017b01fb3afbaffe1a34487cfe36288d2 Mon Sep 17 00:00:00 2001
From: Brandon Wu
Date: Wed, 8 May 2024 21:43:07 -0700
Subject: [PATCH 1/4] [RISCV] Bump Zaamo and Zalrsc to version 1.0
The ratified information can be found here:
https://wiki.riscv.org/display/HOME/Ratified+Extensions
---
.../test/Preprocessor/riscv-target-features.c | 20 +--
llvm/lib/Target/RISCV/RISCVFeatures.td| 8
llvm/test/CodeGen/RISCV/attributes.ll | 16 +++
llvm/test/MC/RISCV/rv32zaamo-invalid.s| 2 +-
llvm/test/MC/RISCV/rv32zaamo-valid.s | 12 +--
llvm/test/MC/RISCV/rv32zalrsc-invalid.s | 2 +-
llvm/test/MC/RISCV/rv32zalrsc-valid.s | 12 +--
llvm/test/MC/RISCV/rv64zaamo-invalid.s| 2 +-
llvm/test/MC/RISCV/rv64zaamo-valid.s | 8
llvm/test/MC/RISCV/rv64zalrsc-invalid.s | 2 +-
llvm/test/MC/RISCV/rv64zalrsc-valid.s | 8
.../TargetParser/RISCVISAInfoTest.cpp | 4 ++--
12 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/clang/test/Preprocessor/riscv-target-features.c
b/clang/test/Preprocessor/riscv-target-features.c
index 913093bb51db6..ead9ac9b4063f 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1554,13 +1554,13 @@
// CHECK-ZVKT-EXT: __riscv_zvkt 100{{$}}
// Experimental extensions
-// RUN: %clang --target=riscv32 -menable-experimental-extensions \
-// RUN: -march=rv32i_zaamo0p2 -E -dM %s \
+// RUN: %clang --target=riscv32 \
+// RUN: -march=rv32i_zaamo1p0 -E -dM %s \
// RUN: -o - | FileCheck --check-prefix=CHECK-ZAAMO-EXT %s
-// RUN: %clang --target=riscv64 -menable-experimental-extensions \
-// RUN: -march=rv64i_zaamo0p2 -E -dM %s \
+// RUN: %clang --target=riscv64 \
+// RUN: -march=rv64i_zaamo1p0 -E -dM %s \
// RUN: -o - | FileCheck --check-prefix=CHECK-ZAAMO-EXT %s
-// CHECK-ZAAMO-EXT: __riscv_zaamo 2000{{$}}
+// CHECK-ZAAMO-EXT: __riscv_zaamo 100{{$}}
// RUN: %clang --target=riscv32 -menable-experimental-extensions \
// RUN: -march=rv32ia_zabha1p0 -E -dM %s \
@@ -1578,13 +1578,13 @@
// RUN: -o - | FileCheck --check-prefix=CHECK-ZALASR-EXT %s
// CHECK-ZALASR-EXT: __riscv_zalasr 1000{{$}}
-// RUN: %clang --target=riscv32 -menable-experimental-extensions \
-// RUN: -march=rv32i_zalrsc0p2 -E -dM %s \
+// RUN: %clang --target=riscv32 \
+// RUN: -march=rv32i_zalrsc1p0 -E -dM %s \
// RUN: -o - | FileCheck --check-prefix=CHECK-ZALRSC-EXT %s
-// RUN: %clang --target=riscv64 -menable-experimental-extensions \
-// RUN: -march=rv64i_zalrsc0p2 -E -dM %s \
+// RUN: %clang --target=riscv64 \
+// RUN: -march=rv64i_zalrsc1p0 -E -dM %s \
// RUN: -o - | FileCheck --check-prefix=CHECK-ZALRSC-EXT %s
-// CHECK-ZALRSC-EXT: __riscv_zalrsc 2000{{$}}
+// CHECK-ZALRSC-EXT: __riscv_zalrsc 100{{$}}
// RUN: %clang --target=riscv32 -menable-experimental-extensions \
// RUN: -march=rv32izfbfmin1p0 -E -dM %s \
diff --git a/llvm/lib/Target/RISCV/RISCVFeatures.td
b/llvm/lib/Target/RISCV/RISCVFeatures.td
index 89e1214f469da..b099496d18388 100644
--- a/llvm/lib/Target/RISCV/RISCVFeatures.td
+++ b/llvm/lib/Target/RISCV/RISCVFeatures.td
@@ -211,8 +211,8 @@ def FeatureStdExtZa128rs : RISCVExtension<"za128rs", 1, 0,
"'Za128rs' (Reservation Set Size of
at Most 128 Bytes)">;
def FeatureStdExtZaamo
-: RISCVExperimentalExtension<"zaamo", 0, 2,
- "'Zaamo' (Atomic Memory Operations)">;
+: RISCVExtension<"zaamo", 1, 0,
+ "'Zaamo' (Atomic Memory Operations)">;
def HasStdExtAOrZaamo
: Predicate<"Subtarget->hasStdExtA() || Subtarget->hasStdExtZaamo()">,
AssemblerPredicate<(any_of FeatureStdExtA, FeatureStdExtZaamo),
@@ -242,8 +242,8 @@ def HasStdExtZalasr :
Predicate<"Subtarget->hasStdExtZalasr()">,
"'Zalasr' (Load-Acquire and Store-Release
Instructions)">;
def FeatureStdExtZalrsc
-: RISCVExperimentalExtension<"zalrsc", 0, 2,
- "'Zalrsc' (Load-Reserved/Store-Conditional)">;
+: RISCVExtension<"zalrsc", 1, 0,
+ "'Zalrsc' (Load-Reserved/Store-Conditional)">;
def HasStdExtAOrZalrsc
: Predicate<"Subtarget->hasStdExtA() || Subtarget->hasStdExtZalrsc()">,
AssemblerPredicate<(any_of FeatureStdExtA, FeatureStdExtZalrsc),
diff --git a/llvm/test/CodeGen/RISCV/attributes.ll
b/llvm/test/CodeGen/RISCV/attributes.ll
index 8f49f6648ad28..9fdd842e5dd37 100644
--- a/llvm/test/CodeGen/RISCV/attributes.ll
+++ b/llvm/test/CodeGen/RISCV/attributes.ll
@@ -112,10
[clang] [llvm] [RISCV] Bump Zaamo and Zalrsc to version 1.0 (PR #91556)
https://github.com/4vtomat updated
https://github.com/llvm/llvm-project/pull/91556
>From 062d7d5017b01fb3afbaffe1a34487cfe36288d2 Mon Sep 17 00:00:00 2001
From: Brandon Wu
Date: Wed, 8 May 2024 21:43:07 -0700
Subject: [PATCH 1/3] [RISCV] Bump Zaamo and Zalrsc to version 1.0
The ratified information can be found here:
https://wiki.riscv.org/display/HOME/Ratified+Extensions
---
.../test/Preprocessor/riscv-target-features.c | 20 +--
llvm/lib/Target/RISCV/RISCVFeatures.td| 8
llvm/test/CodeGen/RISCV/attributes.ll | 16 +++
llvm/test/MC/RISCV/rv32zaamo-invalid.s| 2 +-
llvm/test/MC/RISCV/rv32zaamo-valid.s | 12 +--
llvm/test/MC/RISCV/rv32zalrsc-invalid.s | 2 +-
llvm/test/MC/RISCV/rv32zalrsc-valid.s | 12 +--
llvm/test/MC/RISCV/rv64zaamo-invalid.s| 2 +-
llvm/test/MC/RISCV/rv64zaamo-valid.s | 8
llvm/test/MC/RISCV/rv64zalrsc-invalid.s | 2 +-
llvm/test/MC/RISCV/rv64zalrsc-valid.s | 8
.../TargetParser/RISCVISAInfoTest.cpp | 4 ++--
12 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/clang/test/Preprocessor/riscv-target-features.c
b/clang/test/Preprocessor/riscv-target-features.c
index 913093bb51db6..ead9ac9b4063f 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1554,13 +1554,13 @@
// CHECK-ZVKT-EXT: __riscv_zvkt 100{{$}}
// Experimental extensions
-// RUN: %clang --target=riscv32 -menable-experimental-extensions \
-// RUN: -march=rv32i_zaamo0p2 -E -dM %s \
+// RUN: %clang --target=riscv32 \
+// RUN: -march=rv32i_zaamo1p0 -E -dM %s \
// RUN: -o - | FileCheck --check-prefix=CHECK-ZAAMO-EXT %s
-// RUN: %clang --target=riscv64 -menable-experimental-extensions \
-// RUN: -march=rv64i_zaamo0p2 -E -dM %s \
+// RUN: %clang --target=riscv64 \
+// RUN: -march=rv64i_zaamo1p0 -E -dM %s \
// RUN: -o - | FileCheck --check-prefix=CHECK-ZAAMO-EXT %s
-// CHECK-ZAAMO-EXT: __riscv_zaamo 2000{{$}}
+// CHECK-ZAAMO-EXT: __riscv_zaamo 100{{$}}
// RUN: %clang --target=riscv32 -menable-experimental-extensions \
// RUN: -march=rv32ia_zabha1p0 -E -dM %s \
@@ -1578,13 +1578,13 @@
// RUN: -o - | FileCheck --check-prefix=CHECK-ZALASR-EXT %s
// CHECK-ZALASR-EXT: __riscv_zalasr 1000{{$}}
-// RUN: %clang --target=riscv32 -menable-experimental-extensions \
-// RUN: -march=rv32i_zalrsc0p2 -E -dM %s \
+// RUN: %clang --target=riscv32 \
+// RUN: -march=rv32i_zalrsc1p0 -E -dM %s \
// RUN: -o - | FileCheck --check-prefix=CHECK-ZALRSC-EXT %s
-// RUN: %clang --target=riscv64 -menable-experimental-extensions \
-// RUN: -march=rv64i_zalrsc0p2 -E -dM %s \
+// RUN: %clang --target=riscv64 \
+// RUN: -march=rv64i_zalrsc1p0 -E -dM %s \
// RUN: -o - | FileCheck --check-prefix=CHECK-ZALRSC-EXT %s
-// CHECK-ZALRSC-EXT: __riscv_zalrsc 2000{{$}}
+// CHECK-ZALRSC-EXT: __riscv_zalrsc 100{{$}}
// RUN: %clang --target=riscv32 -menable-experimental-extensions \
// RUN: -march=rv32izfbfmin1p0 -E -dM %s \
diff --git a/llvm/lib/Target/RISCV/RISCVFeatures.td
b/llvm/lib/Target/RISCV/RISCVFeatures.td
index 89e1214f469da..b099496d18388 100644
--- a/llvm/lib/Target/RISCV/RISCVFeatures.td
+++ b/llvm/lib/Target/RISCV/RISCVFeatures.td
@@ -211,8 +211,8 @@ def FeatureStdExtZa128rs : RISCVExtension<"za128rs", 1, 0,
"'Za128rs' (Reservation Set Size of
at Most 128 Bytes)">;
def FeatureStdExtZaamo
-: RISCVExperimentalExtension<"zaamo", 0, 2,
- "'Zaamo' (Atomic Memory Operations)">;
+: RISCVExtension<"zaamo", 1, 0,
+ "'Zaamo' (Atomic Memory Operations)">;
def HasStdExtAOrZaamo
: Predicate<"Subtarget->hasStdExtA() || Subtarget->hasStdExtZaamo()">,
AssemblerPredicate<(any_of FeatureStdExtA, FeatureStdExtZaamo),
@@ -242,8 +242,8 @@ def HasStdExtZalasr :
Predicate<"Subtarget->hasStdExtZalasr()">,
"'Zalasr' (Load-Acquire and Store-Release
Instructions)">;
def FeatureStdExtZalrsc
-: RISCVExperimentalExtension<"zalrsc", 0, 2,
- "'Zalrsc' (Load-Reserved/Store-Conditional)">;
+: RISCVExtension<"zalrsc", 1, 0,
+ "'Zalrsc' (Load-Reserved/Store-Conditional)">;
def HasStdExtAOrZalrsc
: Predicate<"Subtarget->hasStdExtA() || Subtarget->hasStdExtZalrsc()">,
AssemblerPredicate<(any_of FeatureStdExtA, FeatureStdExtZalrsc),
diff --git a/llvm/test/CodeGen/RISCV/attributes.ll
b/llvm/test/CodeGen/RISCV/attributes.ll
index 8f49f6648ad28..9fdd842e5dd37 100644
--- a/llvm/test/CodeGen/RISCV/attributes.ll
+++ b/llvm/test/CodeGen/RISCV/attributes.ll
@@ -112,10
[clang] [llvm] [RISCV] Bump Zaamo and Zalrsc to version 1.0 (PR #91556)
@@ -1554,13 +1554,13 @@
// CHECK-ZVKT-EXT: __riscv_zvkt 100{{$}}
// Experimental extensions
-// RUN: %clang --target=riscv32 -menable-experimental-extensions \
-// RUN: -march=rv32i_zaamo0p2 -E -dM %s \
+// RUN: %clang --target=riscv32 \
4vtomat wrote:
Oh, I see. Thanks for catching this!
https://github.com/llvm/llvm-project/pull/91556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Remove unneeded multiply in RISCV CodeGenTypes (PR #92644)
https://github.com/4vtomat closed https://github.com/llvm/llvm-project/pull/92644 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[jira] [Updated] (CASSANDRA-19649) add absurdfarce's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-19649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19649: - Resolution: Fixed Status: Resolved (was: Triage Needed) Done in r69303. > add absurdfarce's gpg key to project's KEYS file > > > Key: CASSANDRA-19649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19649 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Bret McGuire >Assignee: Brandon Williams >Priority: Normal > Attachments: absurdfarce_keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > [https://dist.apache.org/repos/dist/release/cassandra/KEYS] > My gpg public key here has the fingerprint > 498AAC354AA5CB36FAAB7608B6E83A2D2E447E56 > References: > - [https://www.apache.org/dev/release-signing#keys-policy] > - [http://www.apache.org/legal/release-policy.html] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19649) add absurdfarce's gpg key to project's KEYS file
[ https://issues.apache.org/jira/browse/CASSANDRA-19649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-19649: Assignee: Brandon Williams > add absurdfarce's gpg key to project's KEYS file > > > Key: CASSANDRA-19649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19649 > Project: Cassandra > Issue Type: Task > Components: Packaging >Reporter: Bret McGuire >Assignee: Brandon Williams >Priority: Normal > Attachments: absurdfarce_keys.patch > > > The patch adds my gpg public key to the project's KEYS file found at > [https://dist.apache.org/repos/dist/release/cassandra/KEYS] > My gpg public key here has the fingerprint > 498AAC354AA5CB36FAAB7608B6E83A2D2E447E56 > References: > - [https://www.apache.org/dev/release-signing#keys-policy] > - [http://www.apache.org/legal/release-policy.html] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[RELEASE] Apache Cassandra 4.0.13 released
The Cassandra team is pleased to announce the release of Apache Cassandra version 4.0.13. Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. http://cassandra.apache.org/ Downloads of source and binary distributions are listed in our download section: http://cassandra.apache.org/download/ This version is a bug fix release[1] on the 4.0 series. As always, please pay attention to the release notes[2] and Let us know[3] if you were to encounter any problem. [WARNING] Debian and RedHat package repositories have moved! Debian /etc/apt/sources.list.d/cassandra.sources.list and RedHat /etc/yum.repos.d/cassandra.repo files must be updated to the new repository URLs. For Debian it is now https://debian.cassandra.apache.org . For RedHat it is now https://redhat.cassandra.apache.org/40x/ . Enjoy! [1]: CHANGES.txt https://github.com/apache/cassandra/blob/cassandra-4.0.13/CHANGES.txt [2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-4.0.13/NEWS.txt [3]: https://issues.apache.org/jira/browse/CASSANDRA
[RELEASE] Apache Cassandra 4.0.13 released
The Cassandra team is pleased to announce the release of Apache Cassandra version 4.0.13. Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. http://cassandra.apache.org/ Downloads of source and binary distributions are listed in our download section: http://cassandra.apache.org/download/ This version is a bug fix release[1] on the 4.0 series. As always, please pay attention to the release notes[2] and Let us know[3] if you were to encounter any problem. [WARNING] Debian and RedHat package repositories have moved! Debian /etc/apt/sources.list.d/cassandra.sources.list and RedHat /etc/yum.repos.d/cassandra.repo files must be updated to the new repository URLs. For Debian it is now https://debian.cassandra.apache.org . For RedHat it is now https://redhat.cassandra.apache.org/40x/ . Enjoy! [1]: CHANGES.txt https://github.com/apache/cassandra/blob/cassandra-4.0.13/CHANGES.txt [2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-4.0.13/NEWS.txt [3]: https://issues.apache.org/jira/browse/CASSANDRA
[RELEASE] Apache Cassandra 4.1.5 released
The Cassandra team is pleased to announce the release of Apache Cassandra version 4.1.5. Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. http://cassandra.apache.org/ Downloads of source and binary distributions are listed in our download section: http://cassandra.apache.org/download/ This version is a bug fix release[1] on the 4.1 series. As always, please pay attention to the release notes[2] and Let us know[3] if you were to encounter any problem. [WARNING] Debian and RedHat package repositories have moved! Debian /etc/apt/sources.list.d/cassandra.sources.list and RedHat /etc/yum.repos.d/cassandra.repo files must be updated to the new repository URLs. For Debian it is now https://debian.cassandra.apache.org . For RedHat it is now https://redhat.cassandra.apache.org/41x/ . Enjoy! [1]: CHANGES.txt https://github.com/apache/cassandra/blob/cassandra-4.1.5/CHANGES.txt [2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-4.1.5/NEWS.txt [3]: https://issues.apache.org/jira/browse/CASSANDRA
[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19648: - Status: Needs Committer (was: Patch Available) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847910#comment-17847910 ] Brandon Williams commented on CASSANDRA-19648: -- Simple enough, looks good to me. +1 > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19648: - Test and Documentation Plan: none Status: Patch Available (was: Open) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19648: - Fix Version/s: 5.x (was: 5.1) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19648: - Change Category: Operability Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[RELEASE] Apache Cassandra 4.1.5 released
The Cassandra team is pleased to announce the release of Apache Cassandra version 4.1.5. Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. http://cassandra.apache.org/ Downloads of source and binary distributions are listed in our download section: http://cassandra.apache.org/download/ This version is a bug fix release[1] on the 4.1 series. As always, please pay attention to the release notes[2] and Let us know[3] if you were to encounter any problem. [WARNING] Debian and RedHat package repositories have moved! Debian /etc/apt/sources.list.d/cassandra.sources.list and RedHat /etc/yum.repos.d/cassandra.repo files must be updated to the new repository URLs. For Debian it is now https://debian.cassandra.apache.org . For RedHat it is now https://redhat.cassandra.apache.org/41x/ . Enjoy! [1]: CHANGES.txt https://github.com/apache/cassandra/blob/cassandra-4.1.5/CHANGES.txt [2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-4.1.5/NEWS.txt [3]: https://issues.apache.org/jira/browse/CASSANDRA
Re: [VOTE] Release Apache Cassandra 4.0.13
With five +1 (3 binding including my own) and no -1, the vote passes. I'll get the artifacts published. Kind Regards, Brandon On Thu, May 2, 2024 at 10:16 AM Brandon Williams wrote: > > Proposing the test build of Cassandra 4.0.13 for release. > > sha1: a6fb3b76feb8467d314b116f937322e1989b42e1 > Git: https://github.com/apache/cassandra/tree/4.0.13-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1328/org/apache/cassandra/cassandra-all/4.0.13/ > > The Source and Build Artifacts, and the Debian and RPM packages and > repositories, are available here: > https://dist.apache.org/repos/dist/dev/cassandra/4.0.13/ > > The vote will be open for 72 hours (longer if needed). Everyone who > has tested the build is invited to vote. Votes by PMC members are > considered binding. A vote passes if there are at least three binding > +1s and no -1's. > > [1]: CHANGES.txt: > https://github.com/apache/cassandra/blob/4.0.13-tentative/CHANGES.txt > [2]: NEWS.txt: > https://github.com/apache/cassandra/blob/4.0.13-tentative/NEWS.txt > > Kind Regards, > Brandon
Re: [VOTE] Release Apache Cassandra 4.1.5
With five +1 (4 binding including my own) and no -1, the vote passes. I'll get the artifacts published. On Thu, May 2, 2024 at 11:36 AM Brandon Williams wrote: > > Proposing the test build of Cassandra 4.1.5 for release. > > sha1: 6b134265620d6b39f9771d92edd29abdfd27de6a > Git: https://github.com/apache/cassandra/tree/4.1.5-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1329/org/apache/cassandra/cassandra-all/4.1.5/ > > The Source and Build Artifacts, and the Debian and RPM packages and > repositories, are available here: > https://dist.apache.org/repos/dist/dev/cassandra/4.1.5/ > > The vote will be open for 72 hours (longer if needed). Everyone who > has tested the build is invited to vote. Votes by PMC members are > considered binding. A vote passes if there are at least three binding > +1s and no -1's. > > [1]: CHANGES.txt: > https://github.com/apache/cassandra/blob/4.1.5-tentative/CHANGES.txt > [2]: NEWS.txt: > https://github.com/apache/cassandra/blob/4.1.5-tentative/NEWS.txt
[jira] [Updated] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19645: - Reviewers: Brandon Williams, Stefan Miklosovic (was: Brandon Williams) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.1-alpha1 > > Time Spent: 20m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
