This is an automated email from the ASF dual-hosted git repository.
maciej pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/iggy.git
The following commit(s) were added to refs/heads/master by this push:
new 5cc7c37db fix(docs): fix grammar errors in README, examples, and test
comments (#3011)
5cc7c37db is described below
commit 5cc7c37db790e7a89bace0f433f7249b2c702c44
Author: Jochen Stierberger <[email protected]>
AuthorDate: Mon Mar 23 03:54:45 2026 -0500
fix(docs): fix grammar errors in README, examples, and test comments (#3011)
Closes #3009
---
README.md | 2 +-
.../tests/server/scenarios/log_rotation_scenario.rs | 2 +-
.../server/scenarios/stream_size_validation_scenario.rs | 4 ++--
.../rust/src/message-headers/message-compression/README.md | 12 ++++++------
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/README.md b/README.md
index c6ad96951..a72c08d3d 100644
--- a/README.md
+++ b/README.md
@@ -233,7 +233,7 @@ Run the tests:
Set root user credentials (OPTIONAL):
-Iggy requires credentials to authenticate request to the server.
+Iggy requires credentials to authenticate requests to the server.
You can set the root user **before** starting the server.
(macOS/Linux)
diff --git a/core/integration/tests/server/scenarios/log_rotation_scenario.rs
b/core/integration/tests/server/scenarios/log_rotation_scenario.rs
index a88c74817..85ab143d1 100644
--- a/core/integration/tests/server/scenarios/log_rotation_scenario.rs
+++ b/core/integration/tests/server/scenarios/log_rotation_scenario.rs
@@ -256,7 +256,7 @@ async fn validate_log_rotation_rules(
// The delay in log writing in Iggy mainly depends on the processing speed
// of background threads and the operating system's I/O scheduling, which
// means that the actual size of written logs may be slightly larger than
- // expected. So there ignores tiny minor overflow by comparing integer KB
+ // expected. So this ignores tiny minor overflow by comparing integer KB
// values instead of exact bytes.
let mut total_log_size = IggyByteSize::new(0);
diff --git
a/core/integration/tests/server/scenarios/stream_size_validation_scenario.rs
b/core/integration/tests/server/scenarios/stream_size_validation_scenario.rs
index fef4c339a..c00cdee20 100644
--- a/core/integration/tests/server/scenarios/stream_size_validation_scenario.rs
+++ b/core/integration/tests/server/scenarios/stream_size_validation_scenario.rs
@@ -104,7 +104,7 @@ pub async fn run(harness: &TestHarness) {
// 14. Delete first topic on the first stream
delete_topic(&client, S1_NAME, T1_NAME).await;
- // 15. Validate both streams, first should have it's message count and
size should be reduced by 50%, second stream should be unchanged
+ // 15. Validate both streams, first should have its message count and size
should be reduced by 50%, second stream should be unchanged
validate_stream(&client, S1_NAME, MSGS_SIZE * 2, MSGS_COUNT * 2).await;
validate_stream(&client, S2_NAME, MSGS_SIZE * 4, MSGS_COUNT * 4).await;
@@ -124,7 +124,7 @@ pub async fn run(harness: &TestHarness) {
// 20. Purge second stream
purge_stream(&client, S2_NAME).await;
- // 21. Validate second stream and it's topics, should be empty
+ // 21. Validate second stream and its topics, should be empty
validate_stream(&client, S2_NAME, 0, 0).await;
validate_topic(&client, S2_NAME, T1_NAME, 0, 0).await;
validate_topic(&client, S2_NAME, T2_NAME, 0, 0).await;
diff --git a/examples/rust/src/message-headers/message-compression/README.md
b/examples/rust/src/message-headers/message-compression/README.md
index d0cf5dd70..2301db43d 100644
--- a/examples/rust/src/message-headers/message-compression/README.md
+++ b/examples/rust/src/message-headers/message-compression/README.md
@@ -41,7 +41,7 @@ pub const STREAM_NAME: &str = "compression-stream";
pub const TOPIC_NAME: &str = "compression-topic";
```
-Additionally, set a constant that defines the number of messages to be send to
the server via the producer.
+Additionally, set a constant that defines the number of messages to be sent to
the server via the producer.
```rust
pub const NUM_MESSAGES: u32 = 1000;
@@ -50,12 +50,12 @@ pub const NUM_MESSAGES: u32 = 1000;
### Spotlight: IggyMessage's
In order to add functionality to compress and decompress messages during
transit, we need to know what a message actually is and how it is implemented.
-Iggy implements two important types, that we need to know.
+Iggy implements two important types that we need to know.
*
[IggyMessage](https://github.com/apache/iggy/blob/e46f294b7af4f86b0d7e26d984205a019a8885f8/core/common/src/types/message/iggy_message.rs#L108)
*
[ReceivedMessage](https://github.com/apache/iggy/blob/b26246252502ba6f5d6cad2895e7c468d9f959e4/core/sdk/src/clients/consumer.rs#L905)
-A message send to the server needs to be of type `IggyMessage`.
+A message sent to the server needs to be of type `IggyMessage`.
```Rust
pub struct IggyMessage {
@@ -71,17 +71,17 @@ pub struct IggyMessage {
The important bits in context of this example are the *payload* and the
*user_headers*.
Payload is of type Bytes and corresponds to the actual message that we want to
send to the server.
-Let's suppose our example is an abstraction over a real world scenario, where
some application sends it's application logs to the iggy-server. This
application is therefore the producer.
+Let's suppose our example is an abstraction over a real world scenario, where
some application sends its application logs to the iggy-server. This
application is therefore the producer.
We also have a monitoring service, that inspects the logs of our application
to check for any service disruptions. So this monitoring service needs to read
the logs from the iggy-server and is therefore the consumer.
Further suppose, the application logs are quite large and repetitive, since
they follow a structured pattern (as logs usually do).
-It may be a good idea to reduce bandwidth by trading of some idle CPU time to
compress the logs before sending them to the server.
+It may be a good idea to reduce bandwidth by trading off some idle CPU time to
compress the logs before sending them to the server.
We go straight ahead, implement some compression functionalities and send the
compressed messages to the server.
If the monitoring service now consumes these messages we have a problem. The
logs are still compressed.
Even if we know that the messages are compressed we do not know how to
decompress them because the algorithm that was used for compression is unknown.
This is where `user_headers` become handy.
-The definition above tells us, that user_headers are (optional) Bytes. But
thats because finally everything is serialized before sending to the server.
+The definition above tells us that user_headers are (optional) Bytes. But
that's because finally everything is serialized before sending to the server.
Looking at the implementation of `IggyMessage` we see that user_headers are a
serialized `HashMap` with Iggy specific types `HeaderKey` and `HeaderValue`.
So the user_headers are basically a set of metadata defined by us, the user,
using a key and a value.
