opened Pull Request #2905 on apache/cassandra
#2905 CASSANDRA-19017 trunk: Ensure that empty SAI column indexes do not fail on validation after full-SSTable streaming
opened Pull Request #2904 on apache/cassandra
#2904 CASSANDRA-19017 5.0: Ensure that empty SAI column indexes do not fail on validation after full-SSTable streaming
commented Pull Request #2894 on apache/cassandra
Interesting... in some tests
FileStore.getBlockSizethrowsUnsupportedOperationException
Interesting... in some tests
FileStore.getBlockSizethrowsUnsupportedOperationExceptioncc @blambov
Could not identify why this exception is thrown. Is it possible to catch this exception also to get more detail?
I have been load testing an instance of Thingsboard using Jmeter running on one of our Azure VM, I could test the below Scenario without any issue: 5K Threads, each with one HTTP Request (API...
I have been load testing an instance of Thingsboard using Jmeter running on one of our Azure VM, I could test the below Scenario without any issue: 5K Threads, each with one HTTP Request (API telemetry) and one data point to one device
But when I started a test for 10K Threads with same HTTP request and data point ,I could see multiple requests throwing error such as
- SSL Handshake Exception: Remote host terminated the handshake
- Broken Pipe (write failed)
- Error 500 etc
After reducing threads per second to 500, I had no issues, so i increased it to 650 and saw a few Requests having errors
I found out about the API Rate limits although there were none set I had this issue, I set the API Rate limit with ample of head room but had no luck , reducing the rate limit to a very small range did affect the error percentage.
Server configurations are: Hardware: Azure D2as (2 vCPUs, 8GB RAM)
Software: Thingsboard docker instance, Single Cassandra DB (no load-balancer used), Kafka Messaging Queue with zookeeper
API call: URL/api/v1/ACCESS_TOKEN/telemetry (also tried with URL/api/plugins/plugins/ENTITY_TYPE/ENTITY_ID/timeseries/ANY?Scope=ANY )
Payload = { "var_1": "NUMBER_BETWEEN_1_AND_1000" }
After trying a few solution I did not see any improvements
Any help on resolving this issue is very much appreciated
Thanks!
PS: I am new to servers and load testing.
Initially, I tried restarting the docker container and server, Had no luck
I tried a local VM instance of same docker image , found no errors
I also tried a different Azure VM already hosted , Had the same issue
Added Rate limits higher than the test cases , did not resolve the issue
opened Pull Request #79 on apache/cassandra-sidecar
#79 CASSANDRASC-82 Expose additional SSL configuration options for the Sidecar Service
opened Pull Request #2902 on apache/cassandra
#2902 CASSANDRA-19030: Fix vector quickstart documentation example CQL
Mentioned @cassandra
Join us at the ONLY Data + AI conference in the Bay Area this year! 💡
Use our exclusive code CS2023TWI20 to save 20% on registration. dtsx.io/3DjcagY
Mentioned @cassandra
Pull Request #2899 on apache/cassandra merged by aweisberg
#2899 Fix Paxos V2 prepare response serialization
commented Pull Request #2899 on apache/cassandra
Found a bug in size calculation as well. Removed serializedRejection and put the serialization of maybeConsensusMigratedAt at the end so it doesn't need to be repeated for accept/reject.
commented Pull Request #2894 on apache/cassandra
Interesting... in some tests FileStore.getBlockSize throws UnsupportedOperationException
cc @blambov
opened Pull Request #241 on apache/cassandra-dtest
#241 Debug/slow upgrade tests
commented Pull Request #2894 on apache/cassandra
Unfortunately I found some issues with testing - not the production code, but it was unable to reset and reconfigure the commit log without restarting JVM - that should be fixed with the recent commits;
I'm running tests suite now:
Unfortunately I found some issues with testing - not the production code, but it was unable to reset and reconfigure the commit log without restarting JVM - that should be fixed with the recent commits;
I'm running tests suite now: https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1081/workflows/5c3290dc-5a70-47e0-9a98-23c1db07bbef
commented Pull Request #2894 on apache/cassandra
@jacek-lewandowski, I tried limited testing and didn't see any issues. Didn't see commitlog disk mode in log file and looks like required. Liked your changes and would like to see these changes gets up-streamed to trunk sooner.
opened Pull Request #2900 on apache/cassandra
#2900 Fix DiskSpaceMetricsTest.testFlushSize
commented Pull Request #2896 on apache/cassandra
As latest will dtest oa current features that sounds like a good compromise to me, agreed.
commented Pull Request #2896 on apache/cassandra
big-oa is a separate sstable format, and it needs to be tested. Doing only base junit tests with it is likely sufficient; we can skip dtests (python or in-jvm) on it.
commented Pull Request #2896 on apache/cassandra
Your 'latest' does already run with SCM NONE which is the same as running with oa feature-wise. Do we see value in testing oa by itself?
commented Pull Request #2896 on apache/cassandra
Given test-latest will test tries+oa we could remove all oa test specific jobs to spare CI cycles as they're redundant now?
Actually, it will not test the the big-oa format but the...
Given test-latest will test tries+oa we could remove all oa test specific jobs to spare CI cycles as they're redundant now?
Actually, it will not test the the big-oa format but the bti-da one.
As for dtests, I'm still working on making the relevant changes.