Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
Neither one is GC-free. Each one will create an instance of
[`UUID`](https://docs.oracle.com/javase/8/docs/api/java/util/UUID.html) and
`String`. Scalar replacement might occur, when the JVM is hot enough, but you
should test it on a concrete version of the JVM.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12696831
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
**BTW**: Using `%uuid` as value for
[logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
does not fulfill the **unicity** requirement from the documentation:
> _Optional_. A unique identifier for the log entry. If you provide a value,
> then Logging considers other log entries in the same project, with the same
> timestamp, and with the same `insertId` to be duplicates which are removed in
> a single query result. However, there are no guarantees of de-duplication in
> the export of logs.
> If the `insertId` is omitted when writing a log entry, the Logging API
> assigns its own unique identifier in this field.
The same log event, delivered by different appenders will have different UUIDs.
See #3503 for a discussion.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12696880
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [VOTE] Add branch protection rules to Log4j
Hi Ralph, On 2.04.2025 17:40, Ralph Goers wrote: I am finding this email confusing. I think it is due to the > formatting but I am not sure. I am making my best guess. Sorry, the e-mail client ate some new line characters. Vote 1: Enable certain branch protection features on the code > branches (`2.x` and `main`) of all non-dormant Java repos: > I can’t vote on this as I don’t know what the impact of that is. Should be "Vote 1. Require a pull request before merging". Piotr
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ViliusS edited a comment on the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> **BTW**: Using `%uuid` as value for
> [logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
> does not fulfill the **unicity** requirement from the documentation:
>
> > _Optional_. A unique identifier for the log entry. If you provide a value,
> > then Logging considers other log entries in the same project, with the same
> > timestamp, and with the same `insertId` to be duplicates which are removed
> > in a single query result. However, there are no guarantees of
> > de-duplication in the export of logs.
> > If the `insertId` is omitted when writing a log entry, the Logging API
> > assigns its own unique identifier in this field.
>
> The same log event, delivered by different appenders will have different
> UUIDs. See #3503 for a discussion.
I'm going to propose PR for GcpLayout.json template shortly. Among other
things, counter cannot be used with `logging.googleapis.com/insertId` either
because it produces duplicate IDs for different JVM threads. It also restarts
from ID 1 if Java application is restarted.
I think having different UUID for different appenders are exactly how it is
supposed to work. Different appenders pushing to the same Google Cloud Log
would probably mean different log event formatting anyway, so we should ensure
that such messages are no de-duplicated by GCP.
Alternatively, `insertId` could be omitted completely, so GCP would generate
their own IDs.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12698772
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ViliusS edited a comment on the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> **BTW**: Using `%uuid` as value for
> [logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
> does not fulfill the **unicity** requirement from the documentation:
>
> > _Optional_. A unique identifier for the log entry. If you provide a value,
> > then Logging considers other log entries in the same project, with the same
> > timestamp, and with the same `insertId` to be duplicates which are removed
> > in a single query result. However, there are no guarantees of
> > de-duplication in the export of logs.
> > If the `insertId` is omitted when writing a log entry, the Logging API
> > assigns its own unique identifier in this field.
>
> The same log event, delivered by different appenders will have different
> UUIDs. See #3503 for a discussion.
I'm going to propose PR for GcpLayout.json template shortly. Among other
things, counter cannot be used with `logging.googleapis.com/insertId` either
because it produces duplicate IDs for different JVM threads. It also restarts
if Java application is restarted.
I think having different UUID for different appenders are exactly how it is
supposed to work. Different appenders pushing to the same Google Cloud Log
would probably mean different log event formatting anyway, so we should ensure
that such messages are no de-duplicated by GCP.
Alternatively, `insertId` could be omitted completely, so GCP would generate
their own IDs.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12698772
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> Alternatively, `insertId` could be omitted completely, so GCP would generate
> their own IDs.
This is probably the route I would choose. The only purpose of this value is to
deduplicate log events with the **same timestamp**. Short of creating a
`ContextDataProvider` with a counter, I don't see a reliable way to do that.
Log duplication shouldn't occur anyway, except misconfigurations like:
```xml
```
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12699365
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ViliusS edited a comment on the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> **BTW**: Using `%uuid` as value for
> [logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
> does not fulfill the **unicity** requirement from the documentation:
>
> > _Optional_. A unique identifier for the log entry. If you provide a value,
> > then Logging considers other log entries in the same project, with the same
> > timestamp, and with the same `insertId` to be duplicates which are removed
> > in a single query result. However, there are no guarantees of
> > de-duplication in the export of logs.
> > If the `insertId` is omitted when writing a log entry, the Logging API
> > assigns its own unique identifier in this field.
>
> The same log event, delivered by different appenders will have different
> UUIDs. See #3503 for a discussion.
I'm going to propose PR for GcpLayout.json template shortly. Among other
things, counter cannot be used with `logging.googleapis.com/insertId` either
because it produces duplicate IDs for different JVM threads. It also restarts
from ID 1 if Java application is restarted.
I think having different UUID for different appenders are exactly how it is
supposed to work. Different appenders pushing to the same Google Cloud Log
would probably mean different log event formatting anyway, so we should ensure
that such messages are not de-duplicated by GCP.
Alternatively, `insertId` could be omitted completely, so GCP would generate
their own IDs.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12698772
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ViliusS added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> **BTW**: Using `%uuid` as value for
> [logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
> does not fulfill the **unicity** requirement from the documentation:
>
> > _Optional_. A unique identifier for the log entry. If you provide a value,
> > then Logging considers other log entries in the same project, with the same
> > timestamp, and with the same `insertId` to be duplicates which are removed
> > in a single query result. However, there are no guarantees of
> > de-duplication in the export of logs.
> > If the `insertId` is omitted when writing a log entry, the Logging API
> > assigns its own unique identifier in this field.
>
> The same log event, delivered by different appenders will have different
> UUIDs. See #3503 for a discussion.
I'm going to propose PR for GcpLayout.json template shortly. Among other
things, counter cannot be used with `logging.googleapis.com/insertId` either
because it produces duplicate IDs for different JVM threads. It also restarts
if Java application is restarted.
I think having different UUID for different appenders are exactly how it is
supposed to work. Different appenders pushing to the same Google Cloud Log
would probably mean different log event formatting anyway, so we should ensure
that such messages are no de-duplicated by GCP.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12698772
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
