You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "vy (via GitHub)" <gi...@apache.org> on 2023/12/18 11:08:31 UTC

[PR] Move JCTools-based queues to a new `log4j-jctools` module (logging-log4j2)

vy opened a new pull request, #2104:
URL: https://github.com/apache/logging-log4j2/pull/2104

   This PR addresses #2075 by means of following changes:
   - Recycler factories in the API are converted to `ServiceProvider`s
   - JCTools dependencies in `log4j-api` and `log4j-core` are removed in favor of a new module: `log4j-jctools`
   
   ### Why does `log4j-jctools` depend on `log4j-core`?
   
   There are two places where JCTools is used as an optional dependency:
   1. In `log4j-api` as a `Recycler[Factory]` (used almost everywhere) implementation
   2. In `log4j-core` as a `BlockingQueueFactory` (used by `AsyncAppender` in `log4j-core`) implementation
   
   There are two approaches I can think of to remove the JCTools optional dependencies:
   1. Hoist `BlockingQueueFactory` from `log4j-core` to `log4j-api`
      - :smiley: `log4j-jctools` will only need to depend on `log4j-api`
      - :frowning_face: `log4j-api` will be introduced a component that only matters for some `log4j-core` internal
      - :frowning_face: `log4j-core` has access to plugins and hence, users were expected to provide custom `@Configurable @Plugin BlockingQueueFactory` implementations that they can refer to in `log4j2.xml`. Though moving `BlockingQueueFactory` to `log4j-api` will break this contract completely, since `log4j-api` has no notion of plugins.
   2. Make `log4j-jctools` depend on `log4j-core` and provide both `Recycler[Factory]` and `BlockingQueueFactory` implementations
      - :frowning_face: Users who wants a JCTools-based recycler, but no `log4j-core` et al. (if there is such a use case at all) needs to manually exclude `log4j-core`
   
   ### Review kit
   
   1. You can safely ignore files changed due to package relocations.
   1. Start with changes in `o.a.l.log4j.internal.recycler` and `o.a.l.log4j.spi` packages of `log4j-api` module
   1. Proceed to `log4j-core`
   1. Now it is safe to check `log4j-jctools`


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Move JCTools-based queues to a new `log4j-jctools` module (logging-log4j2)

Posted by "vy (via GitHub)" <gi...@apache.org>.
vy merged PR #2104:
URL: https://github.com/apache/logging-log4j2/pull/2104


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Move JCTools-based queues to a new `log4j-jctools` module (logging-log4j2)

Posted by "vy (via GitHub)" <gi...@apache.org>.
vy commented on PR #2104:
URL: https://github.com/apache/logging-log4j2/pull/2104#issuecomment-1861503334

   > I start to wonder how useful is it to fill `log4j-api` with partial implementations. For example a recycled `LogBuilder` is useful for `log4j-core`, but not so much for `log4j-to-slf4j`. If `log4j-to-slf4j` is bound to Logback, the Log4j API builder will be recycled, but the underlying SLF4J builder won't. We might as well remove `Recycler` from `AbstractLogger` and move it into `core.Logger`.
   
   Created #2106 and linked to it in #2016.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Move JCTools-based queues to a new `log4j-jctools` module (logging-log4j2)

Posted by "ppkarwasz (via GitHub)" <gi...@apache.org>.
ppkarwasz commented on code in PR #2104:
URL: https://github.com/apache/logging-log4j2/pull/2104#discussion_r1430031071


##########
log4j-api/src/main/java/org/apache/logging/log4j/spi/recycler/RecyclerFactoryProvider.java:
##########
@@ -0,0 +1,59 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to you under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.logging.log4j.spi.recycler;
+
+import edu.umd.cs.findbugs.annotations.Nullable;
+import org.apache.logging.log4j.util.PropertyEnvironment;
+
+/**
+ * Contract for providing {@link RecyclerFactory} instances.
+ *
+ * @since 3.0.0
+ */
+public interface RecyclerFactoryProvider {
+
+    /**
+     * Denotes the value to be used while sorting recycler factory providers to determine the precedence order.
+     * Values will be sorted naturally, that is, lower values will imply higher precedence.
+     *
+     * @return the value to be used while sorting
+     */
+    default int getOrder() {
+        return 100;
+    }
+
+    /**
+     * The name of this recycler factory provider.
+     * Recycler factory providers are required to have unique names.
+     *
+     * @return the name of this recycler factory provider
+     */
+    String getName();

Review Comment:
   In the future we might consider using `ServiceLoader.Provider<RecyclerFactory>` instead of this class and add an `@Named` and `@Order` annotation to the implementations of `RecyclerFactory`. We already have a `@Named` and `@Order` annotation in `log4j-core` and `log4j-plugins`. @jvz, what do you think?
   
   I could open an issue to explore this direction, although I don't have too much confidence in `ServiceLoader#stream`, which is the only way to obtain `ServiceLoader.Provider` instances: it is unable to skip faulty service implementations.



##########
log4j-api/src/main/java/org/apache/logging/log4j/internal/recycler/ThreadLocalRecyclerFactoryProvider.java:
##########
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to you under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.logging.log4j.internal.recycler;
+
+import static java.util.Objects.requireNonNull;
+import static org.apache.logging.log4j.spi.recycler.Recycler.DEFAULT_CAPACITY;
+
+import aQute.bnd.annotation.spi.ServiceProvider;
+import edu.umd.cs.findbugs.annotations.Nullable;
+import java.util.Queue;
+import java.util.function.Consumer;
+import java.util.function.Supplier;
+import org.apache.logging.log4j.spi.LoggingSystemProperty;
+import org.apache.logging.log4j.spi.recycler.AbstractRecycler;
+import org.apache.logging.log4j.spi.recycler.Recycler;
+import org.apache.logging.log4j.spi.recycler.RecyclerFactory;
+import org.apache.logging.log4j.spi.recycler.RecyclerFactoryProvider;
+import org.apache.logging.log4j.util.PropertyEnvironment;
+
+/**
+ * A {@link Recycler} factory provider such that the recycler pools objects in a fixed-size queue stored in a {@link ThreadLocal}.
+ * <p>
+ * This strategy may not be appropriate in workloads where units of work are independent of operating system threads such as reactive streams, coroutines, or virtual threads.
+ * For such use cases, see {@link QueueingRecyclerFactoryProvider}.
+ * </p>
+ *
+ * @since 3.0.0
+ */
+@ServiceProvider(RecyclerFactoryProvider.class)
+public final class ThreadLocalRecyclerFactoryProvider implements RecyclerFactoryProvider {
+
+    @Override
+    public int getOrder() {
+        return 700;
+    }
+
+    @Override
+    public String getName() {
+        return "threadLocal";
+    }
+
+    @Nullable
+    @Override
+    public RecyclerFactory createForEnvironment(PropertyEnvironment environment) {
+        requireNonNull(environment, "environment");
+        final boolean threadLocalEnabled =
+                environment.getBooleanProperty(LoggingSystemProperty.THREAD_LOCALS_ENABLE, true);
+        if (!threadLocalEnabled) {
+            return null;
+        }

Review Comment:
   I would just drop (and document) the support for the `ThreadLocals.enable`.
   
   Unless I am mistaken it was only used in the recycling process, setting `ThreadLocals.enable=false` never disabled **all** thread locals. For example `ThreadContext` still used them. The `ThreadLocals.enable` property seems misleading and deprecated, since `Recycler.factory` replaces it.



##########
log4j-api/src/main/java/org/apache/logging/log4j/spi/recycler/package-info.java:
##########
@@ -0,0 +1,26 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+/**
+ * Internal interfaces and classes to be used by authors of logging implementations or for internal use by
+ * API classes.
+ */
+@Export
+@Version("2.20.1")

Review Comment:
   ```suggestion
   @Version("3.0.0")
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Move JCTools-based queues to a new `log4j-jctools` module (logging-log4j2)

Posted by "vy (via GitHub)" <gi...@apache.org>.
vy commented on code in PR #2104:
URL: https://github.com/apache/logging-log4j2/pull/2104#discussion_r1430588626


##########
log4j-api/src/main/java/org/apache/logging/log4j/internal/recycler/ThreadLocalRecyclerFactoryProvider.java:
##########
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to you under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.logging.log4j.internal.recycler;
+
+import static java.util.Objects.requireNonNull;
+import static org.apache.logging.log4j.spi.recycler.Recycler.DEFAULT_CAPACITY;
+
+import aQute.bnd.annotation.spi.ServiceProvider;
+import edu.umd.cs.findbugs.annotations.Nullable;
+import java.util.Queue;
+import java.util.function.Consumer;
+import java.util.function.Supplier;
+import org.apache.logging.log4j.spi.LoggingSystemProperty;
+import org.apache.logging.log4j.spi.recycler.AbstractRecycler;
+import org.apache.logging.log4j.spi.recycler.Recycler;
+import org.apache.logging.log4j.spi.recycler.RecyclerFactory;
+import org.apache.logging.log4j.spi.recycler.RecyclerFactoryProvider;
+import org.apache.logging.log4j.util.PropertyEnvironment;
+
+/**
+ * A {@link Recycler} factory provider such that the recycler pools objects in a fixed-size queue stored in a {@link ThreadLocal}.
+ * <p>
+ * This strategy may not be appropriate in workloads where units of work are independent of operating system threads such as reactive streams, coroutines, or virtual threads.
+ * For such use cases, see {@link QueueingRecyclerFactoryProvider}.
+ * </p>
+ *
+ * @since 3.0.0
+ */
+@ServiceProvider(RecyclerFactoryProvider.class)
+public final class ThreadLocalRecyclerFactoryProvider implements RecyclerFactoryProvider {
+
+    @Override
+    public int getOrder() {
+        return 700;
+    }
+
+    @Override
+    public String getName() {
+        return "threadLocal";
+    }
+
+    @Nullable
+    @Override
+    public RecyclerFactory createForEnvironment(PropertyEnvironment environment) {
+        requireNonNull(environment, "environment");
+        final boolean threadLocalEnabled =
+                environment.getBooleanProperty(LoggingSystemProperty.THREAD_LOCALS_ENABLE, true);
+        if (!threadLocalEnabled) {
+            return null;
+        }

Review Comment:
   Created #2105 and linked to it in #2016.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org