[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers
by Marián Macik (JIRA)
[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ]
Marián Macik commented on WFLY-9631:
------------------------------------
Hi guys, I see that this is now unassigned. Is there a plan to look at this issue in the near future?
> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
> Key: WFLY-9631
> URL: https://issues.jboss.org/browse/WFLY-9631
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
> Reporter: Marián Macik
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it? For further configuration details, check the Environment field.
> Thank you very much!
> Marian Macik
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10904) Lower logging level of messages for OpenTracing
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-10904?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFLY-10904:
------------------------------------
Thank you Juraci.
bq. Alright. I'll assume it's fine then, as they are logged at different levels and potentially only one of them might exist depending on the setup.
I agree it is not blocker now. Logging looks much better, although I have created a followup issue WFLY-10919. In case that DEBUG level is enabled, both INFO and DEBUG log messages are printed together.
> Lower logging level of messages for OpenTracing
> -----------------------------------------------
>
> Key: WFLY-10904
> URL: https://issues.jboss.org/browse/WFLY-10904
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> Current logging for OpenTracing is quite verbose logging long messages in INFO level, e.g.:
> {code}
> 17:38:45,359 INFO [io.jaegertracing.internal.senders.SenderResolver] (ServerService Thread Pool -- 28) Using sender UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0))
> 17:38:45,395 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 28) Initialized tracer=JaegerTracer(version=Java-0.30.4, serviceName=deployment.war, reporter=RemoteReporter(queueProcessor=RemoteReporter.QueueProcessor(open=true), sender=UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0)), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, serviceName=deployment.war, manager=HttpSamplingManager(gson={serializeNulls:false,factories:[Factory[typeHierarchy=com.google.gson.JsonElement,adapter=com.google.gson.internal.bind.TypeAdapters$29@5795d61d], com.google.gson.internal.bind.ObjectTypeAdapter$1@7286f924, com.google.gson.internal.Excluder@10bd7673, Factory[type=java.lang.String,adapter=com.google.gson.internal.bind.TypeAdapters$16@56577ab9], Factory[type=java.lang.Integer+int,adapter=com.google.gson.internal.bind.TypeAdapters$7@2f0b6b50], Factory[type=java.lang.Boolean+boolean,adapter=com.google.gson.internal.bind.TypeAdapters$3@6a01f84c], Factory[type=java.lang.Byte+byte,adapter=com.google.gson.internal.bind.TypeAdapters$5@11f41591], Factory[type=java.lang.Short+short,adapter=com.google.gson.internal.bind.TypeAdapters$6@7c9b37a4], Factory[type=java.lang.Long+long,adapter=com.google.gson.internal.bind.TypeAdapters$11@8be828c], Factory[type=java.lang.Double+double,adapter=com.google.gson.Gson$1@6d18d84f], Factory[type=java.lang.Float+float,adapter=com.google.gson.Gson$2@5c7110e0], Factory[type=java.lang.Number,adapter=com.google.gson.internal.bind.TypeAdapters$14@79f22add], Factory[type=java.util.concurrent.atomic.AtomicInteger,adapter=com.google.gson.TypeAdapter$1@5a47d8d], Factory[type=java.util.concurrent.atomic.AtomicBoolean,adapter=com.google.gson.TypeAdapter$1@2ed507d6], Factory[type=java.util.concurrent.atomic.AtomicLong,adapter=com.google.gson.TypeAdapter$1@7af7f4fc], Factory[type=java.util.concurrent.atomic.AtomicLongArray,adapter=com.google.gson.TypeAdapter$1@123b9dbd], Factory[type=java.util.concurrent.atomic.AtomicIntegerArray,adapter=com.google.gson.TypeAdapter$1@3455c262], Factory[type=java.lang.Character+char,adapter=com.google.gson.internal.bind.TypeAdapters$15@32b89889], Factory[type=java.lang.StringBuilder,adapter=com.google.gson.internal.bind.TypeAdapters$19@772dda36], Factory[type=java.lang.StringBuffer,adapter=com.google.gson.internal.bind.TypeAdapters$20@3935671b], Factory[type=java.math.BigDecimal,adapter=com.google.gson.internal.bind.TypeAdapters$17@23e9f48d], Factory[type=java.math.BigInteger,adapter=com.google.gson.internal.bind.TypeAdapters$18@55634ca9], Factory[type=java.net.URL,adapter=com.google.gson.internal.bind.TypeAdapters$21@4c06d059], Factory[type=java.net.URI,adapter=com.google.gson.internal.bind.TypeAdapters$22@5e997b7d], Factory[type=java.util.UUID,adapter=com.google.gson.internal.bind.TypeAdapters$24@3238a1bf], Factory[type=java.util.Currency,adapter=com.google.gson.TypeAdapter$1@7d71b555], Factory[type=java.util.Locale,adapter=com.google.gson.internal.bind.TypeAdapters$28@70f36ba], Factory[typeHierarchy=java.net.InetAddress,adapter=com.google.gson.internal.bind.TypeAdapters$23@12d8e7b5], Factory[type=java.util.BitSet,adapter=com.google.gson.TypeAdapter$1@659a9908], com.google.gson.internal.bind.DateTypeAdapter$1@153143f3, Factory[type=java.util.Calendar+java.util.GregorianCalendar,adapter=com.google.gson.internal.bind.TypeAdapters$27@6bf50d09], com.google.gson.internal.bind.TimeTypeAdapter$1@3e45ba8d, com.google.gson.internal.bind.SqlDateTypeAdapter$1@f262694, com.google.gson.internal.bind.TypeAdapters$26@1017c258, com.google.gson.internal.bind.ArrayTypeAdapter$1@53c90816, Factory[type=java.lang.Class,adapter=com.google.gson.TypeAdapter$1@40cb5130], com.google.gson.internal.bind.CollectionTypeAdapterFactory@7e67cd3b, com.google.gson.internal.bind.MapTypeAdapterFactory@504cd5ad, com.google.gson.internal.bind.JsonAdapterAnnotationTypeAdapterFactory@4b5efe0a, com.google.gson.internal.bind.TypeAdapters$30@51066480, com.google.gson.internal.bind.ReflectiveTypeAdapterFactory@11c8758e],instanceCreators:{}}, hostPort=localhost:5778), metrics=io.jaegertracing.internal.metrics.Metrics@279f3ba7, sampler=ProbabilisticSampler(positiveSamplingBoundary=9223372036854776, negativeSamplingBoundary=-9223372036854776, samplingRate=0.001, tags={sampler.type=probabilistic, sampler.param=0.001})), ipv4=2130706433, tags={hostname=rhel7-large-74052, jaeger.version=Java-0.30.4, ip=127.0.0.1}, zipkinSharedRpcSpan=false, baggageSetter=io.jaegertracing.internal.baggage.BaggageSetter@1b8d3ff0, expandExceptionLogs=false)
> {code}
> I think these messages are not useful on INFO level and should be lowered to either DEBUG or TRACE level.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10919) INFO message Initialized tracer=JaegerTracer is too verbose
by Jan Stourac (JIRA)
Jan Stourac created WFLY-10919:
----------------------------------
Summary: INFO message Initialized tracer=JaegerTracer is too verbose
Key: WFLY-10919
URL: https://issues.jboss.org/browse/WFLY-10919
Project: WildFly
Issue Type: Bug
Components: MP OpenTracing
Affects Versions: 14.0.0.Beta2
Reporter: Jan Stourac
Assignee: Juraci Paixão Kröhling
Following log message is logged during the deploy operation of a deployment:
{code}
10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer=JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
{code}
This information is too verbose for INFO level. I propose to do one of following:
# Remove this log message from INFO level - note that very similar message is also logged on DEBUG level:
{code}
10:52:11,714 DEBUG [org.wildfly.microprofile.opentracing.smallrye] (ServerService Thread Pool -- 72) WFLYTRAC0001: Tracer initialized: JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
{code}
# Simplify the log message on INFO level to something simple, like:
{code}
10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer for service helloworld-rs.war
{code}
This issue is a followup of a WFLY-10904.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10876) Align jar file provided for MP OpenTracing into right modules
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-10876?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFLY-10876:
------------------------------------
Note, with [the PR|https://github.com/wildfly/wildfly/pull/11577] new structure of the files mentioned in this issue is following and looks okay now:
{code}
$ for file in gson-*.jar jaeger-core-*.jar jaeger-thrift-*.jar opentracing-api-*.jar opentracing-concurrent-*.jar opentracing-jaxrs2-*.jar opentracing-noop-*.jar opentracing-tracerresolver-*.jar opentracing-util-*.jar opentracing-web-servlet-filter-*.jar smallrye-opentracing-*.jar wildfly-microprofile-opentracing-smallrye-*.jar; do find . -name "$file"; done
./system/layers/base/com/google/code/gson/main/gson-2.8.2.jar
./system/layers/base/io/jaegertracing/jaeger-core/main/jaeger-core-0.30.6.jar
./system/layers/base/io/jaegertracing/jaeger-thrift/main/jaeger-thrift-0.30.6.jar
./system/layers/base/io/opentracing/opentracing-api/main/opentracing-api-0.31.0.jar
./system/layers/base/io/opentracing/contrib/opentracing-concurrent/main/opentracing-concurrent-0.1.0.jar
./system/layers/base/io/opentracing/contrib/opentracing-jaxrs2/main/opentracing-jaxrs2-0.1.7.jar
./system/layers/base/io/opentracing/opentracing-noop/main/opentracing-noop-0.31.0.jar
./system/layers/base/io/opentracing/contrib/opentracing-tracerresolver/main/opentracing-tracerresolver-0.1.5.jar
./system/layers/base/io/opentracing/opentracing-util/main/opentracing-util-0.31.0.jar
./system/layers/base/io/opentracing/contrib/opentracing-web-servlet-filter/main/opentracing-web-servlet-filter-0.1.0.jar
./system/layers/base/io/smallrye/opentracing/main/smallrye-opentracing-1.1.1.jar
./system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/wildfly-microprofile-opentracing-smallrye-14.0.0.CR1-SNAPSHOT.jar
{code}
> Align jar file provided for MP OpenTracing into right modules
> -------------------------------------------------------------
>
> Key: WFLY-10876
> URL: https://issues.jboss.org/browse/WFLY-10876
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: James Perkins
> Priority: Critical
>
> With recent addition of MicroProfile OpenTracing implementation we currently have following set of jar files that are in the build to provide various MicroProfile features:
> {code}
> $ find modules | grep smallrye | grep jar$ | xargs ls -hl
> -rw-rw-r--. 1 jstourac jstourac 39K Aug 16 15:13 modules/system/layers/base/io/smallrye/config/main/smallrye-config-1.3.3.jar
> -rw-rw-r--. 1 jstourac jstourac 8.9K Aug 16 15:13 modules/system/layers/base/io/smallrye/health/main/smallrye-health-1.0.2.jar
> -rw-rw-r--. 1 jstourac jstourac 38K Aug 16 15:13 modules/system/layers/base/org/wildfly/extension/microprofile/config-smallrye/main/wildfly-microprofile-config-smallrye-14.0.0.CR1-SNAPSHOT.jar
> -rw-rw-r--. 1 jstourac jstourac 27K Aug 16 15:13 modules/system/layers/base/org/wildfly/extension/microprofile/health-smallrye/main/wildfly-microprofile-health-smallrye-14.0.0.CR1-SNAPSHOT.jar
> -rw-rw-r--. 1 jstourac jstourac 228K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/gson-2.8.2.jar
> -rw-rw-r--. 1 jstourac jstourac 123K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/jaeger-core-0.30.4.jar
> -rw-rw-r--. 1 jstourac jstourac 2.8M Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/jaeger-thrift-0.30.4.jar
> -rw-rw-r--. 1 jstourac jstourac 14K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-api-0.31.0.jar
> -rw-rw-r--. 1 jstourac jstourac 7.5K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-concurrent-0.1.0.jar
> -rw-rw-r--. 1 jstourac jstourac 41K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-jaxrs2-0.1.6.jar
> -rw-rw-r--. 1 jstourac jstourac 11K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-noop-0.31.0.jar
> -rw-rw-r--. 1 jstourac jstourac 7.4K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-tracerresolver-0.1.5.jar
> -rw-rw-r--. 1 jstourac jstourac 7.9K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-util-0.31.0.jar
> -rw-rw-r--. 1 jstourac jstourac 13K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-web-servlet-filter-0.1.0.jar
> -rw-rw-r--. 1 jstourac jstourac 5.4K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/smallrye-opentracing-1.1.1.jar
> -rw-rw-r--. 1 jstourac jstourac 11K Aug 16 15:13 modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/wildfly-microprofile-opentracing-smallrye-14.0.0.CR1-SNAPSHOT.jar
> {code}
> It looks like the opentracing-smallrye module could be split up into a few separate modules. There at least two motivations:
> # particular implementation into its own module separate from the e.g. microprofile specification
> # because of the way how current patching mechanism works in WildFly, if we leave current {{opentracing-smallrye}} module as is, in case of a one-off patch it would mean to replace all files in the module - currently 3.3MB:
> {code}
> $ du -h modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/
> 3.3M modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/
> {code}
> My proposal how to align the jar files is following:
> # jaeger specific files should go into separate jaeger module
> # {{wildfly-microprofile-opentracing-smallrye-14.0.0.CR1-SNAPSHOT.jar}} should be moved to new {{modules/system/layers/base/org/wildfly/extension/microprofile/opentracing-smallrye}} module so it matches what is done for {{health-smallrye}} and {{config-smallrye}} in extension subdir
> # {{smallrye-opentracing-1.1.1.jar}} should be moved to {{base/io}} as is done for {{config}} and {{health}} - {{modules/system/layers/base/io/smallrye/opentracing/main/smallrye-opentracing-1.1.1.jar}}
> # what about that {{gson-2.8.2.jar}} dependency? Shall it be moved to some more generic place?
> This would give us following structure:
> {code}
> modules/system/layers/base/io/smallrye/config/main/smallrye-config-1.3.3.jar
> modules/system/layers/base/io/smallrye/health/main/smallrye-health-1.0.2.jar
> modules/system/layers/base/io/smallrye/opentracing/main/smallrye-opentracing-1.1.1.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-api-0.31.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-jaxrs2-0.1.6.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-concurrent-0.1.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-web-servlet-filter-0.1.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-noop-0.31.0.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-tracerresolver-0.1.5.jar
> modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/opentracing-util-0.31.0.jar
> modules/system/layers/base/org/wildfly/extension/microprofile/health-smallrye/main/wildfly-microprofile-health-smallrye-14.0.0.CR1-SNAPSHOT.jar
> modules/system/layers/base/org/wildfly/extension/microprofile/config-smallrye/main/wildfly-microprofile-config-smallrye-14.0.0.CR1-SNAPSHOT.jar
> modules/system/layers/base/org/wildfly/extension/microprofile/opentracing-smallrye/main/wildfly-microprofile-opentracing-smallrye-14.0.0.CR1-SNAPSHOT.jar
> ---- I have no idea how this module for jaeger should be named...
> modules/system/layers/base/org/wildfly/microprofile/jaeger/opentracing-smallrye/main/jaeger-thrift-0.30.4.jar
> modules/system/layers/base/org/wildfly/microprofile/jaeger/opentracing-smallrye/main/jaeger-core-0.30.4.jar
> ---- I have no idea how this module for gson should be named...
> modules/system/layers/base/org/wildfly/gson/main/gson-2.8.2.jar
> {code}
> One additional piece for consideration - maybe we should also split up jar files that are just the microprofile-opentracing specification (api at least I guess) apart from the others in the {{modules/system/layers/base/org/wildfly/microprofile/opentracing-smallrye/main/}}
> What do you think?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1642) Compilation error on JDK 11: cannot find class sun.reflect.Reflection
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-1642?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on ELY-1642:
----------------------------------
As long as Java 8 support is required, this class needs to be referenced. Use the jdk-misc artifact via compiler and dependency plugins to add these classes (see https://github.com/wildfly/wildfly-common/blob/master/pom.xml#L116 for an example). Use the MR JAR build approach to support both old and new APIs (requires that the latest supported JDK be used for build, and that prior JDK(s) be available for test running).
> Compilation error on JDK 11: cannot find class sun.reflect.Reflection
> ---------------------------------------------------------------------
>
> Key: ELY-1642
> URL: https://issues.jboss.org/browse/ELY-1642
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Security Manager
> Affects Versions: 1.5.1.Final
> Environment: openjdk version "11-ea" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11-ea+25)
> OpenJDK 64-Bit Server VM 18.9 (build 11-ea+25, mixed mode)
> Reporter: Ondrej Kotek
> Assignee: Justin Cook
> Priority: Critical
> Fix For: 1.7.0.CR1
>
>
> {{mvn test}} results in compilation error:
> {noformat}
> [ERROR] /home/okotek/git/wildfly-elytron/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[58,19] cannot find symbol
> symbol: class Reflection
> location: package sun.reflect
> {noformat}
> Blocks testing on JDK 11, setting to Critical.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10904) Lower logging level of messages for OpenTracing
by Juraci Paixão Kröhling (JIRA)
[ https://issues.jboss.org/browse/WFLY-10904?page=com.atlassian.jira.plugin... ]
Juraci Paixão Kröhling commented on WFLY-10904:
-----------------------------------------------
{quote}
I just wanted to show that removing INFO level in this case actually does not remove any information as it is there still on DEBUG level.
{quote}
Alright. I'll assume it's fine then, as they are logged at different levels and potentially only one of them might exist depending on the setup.
{quote}
I think I cannot reproduce it
{quote}
The JAX-RS message has been removed: https://github.com/opentracing-contrib/java-jaxrs/pull/94
If the log is set to JUL's FINE (not sure which level relates to JBoss Logging), you should see a more verbose variant of that message.
> Lower logging level of messages for OpenTracing
> -----------------------------------------------
>
> Key: WFLY-10904
> URL: https://issues.jboss.org/browse/WFLY-10904
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> Current logging for OpenTracing is quite verbose logging long messages in INFO level, e.g.:
> {code}
> 17:38:45,359 INFO [io.jaegertracing.internal.senders.SenderResolver] (ServerService Thread Pool -- 28) Using sender UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0))
> 17:38:45,395 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 28) Initialized tracer=JaegerTracer(version=Java-0.30.4, serviceName=deployment.war, reporter=RemoteReporter(queueProcessor=RemoteReporter.QueueProcessor(open=true), sender=UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0)), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, serviceName=deployment.war, manager=HttpSamplingManager(gson={serializeNulls:false,factories:[Factory[typeHierarchy=com.google.gson.JsonElement,adapter=com.google.gson.internal.bind.TypeAdapters$29@5795d61d], com.google.gson.internal.bind.ObjectTypeAdapter$1@7286f924, com.google.gson.internal.Excluder@10bd7673, Factory[type=java.lang.String,adapter=com.google.gson.internal.bind.TypeAdapters$16@56577ab9], Factory[type=java.lang.Integer+int,adapter=com.google.gson.internal.bind.TypeAdapters$7@2f0b6b50], Factory[type=java.lang.Boolean+boolean,adapter=com.google.gson.internal.bind.TypeAdapters$3@6a01f84c], Factory[type=java.lang.Byte+byte,adapter=com.google.gson.internal.bind.TypeAdapters$5@11f41591], Factory[type=java.lang.Short+short,adapter=com.google.gson.internal.bind.TypeAdapters$6@7c9b37a4], Factory[type=java.lang.Long+long,adapter=com.google.gson.internal.bind.TypeAdapters$11@8be828c], Factory[type=java.lang.Double+double,adapter=com.google.gson.Gson$1@6d18d84f], Factory[type=java.lang.Float+float,adapter=com.google.gson.Gson$2@5c7110e0], Factory[type=java.lang.Number,adapter=com.google.gson.internal.bind.TypeAdapters$14@79f22add], Factory[type=java.util.concurrent.atomic.AtomicInteger,adapter=com.google.gson.TypeAdapter$1@5a47d8d], Factory[type=java.util.concurrent.atomic.AtomicBoolean,adapter=com.google.gson.TypeAdapter$1@2ed507d6], Factory[type=java.util.concurrent.atomic.AtomicLong,adapter=com.google.gson.TypeAdapter$1@7af7f4fc], Factory[type=java.util.concurrent.atomic.AtomicLongArray,adapter=com.google.gson.TypeAdapter$1@123b9dbd], Factory[type=java.util.concurrent.atomic.AtomicIntegerArray,adapter=com.google.gson.TypeAdapter$1@3455c262], Factory[type=java.lang.Character+char,adapter=com.google.gson.internal.bind.TypeAdapters$15@32b89889], Factory[type=java.lang.StringBuilder,adapter=com.google.gson.internal.bind.TypeAdapters$19@772dda36], Factory[type=java.lang.StringBuffer,adapter=com.google.gson.internal.bind.TypeAdapters$20@3935671b], Factory[type=java.math.BigDecimal,adapter=com.google.gson.internal.bind.TypeAdapters$17@23e9f48d], Factory[type=java.math.BigInteger,adapter=com.google.gson.internal.bind.TypeAdapters$18@55634ca9], Factory[type=java.net.URL,adapter=com.google.gson.internal.bind.TypeAdapters$21@4c06d059], Factory[type=java.net.URI,adapter=com.google.gson.internal.bind.TypeAdapters$22@5e997b7d], Factory[type=java.util.UUID,adapter=com.google.gson.internal.bind.TypeAdapters$24@3238a1bf], Factory[type=java.util.Currency,adapter=com.google.gson.TypeAdapter$1@7d71b555], Factory[type=java.util.Locale,adapter=com.google.gson.internal.bind.TypeAdapters$28@70f36ba], Factory[typeHierarchy=java.net.InetAddress,adapter=com.google.gson.internal.bind.TypeAdapters$23@12d8e7b5], Factory[type=java.util.BitSet,adapter=com.google.gson.TypeAdapter$1@659a9908], com.google.gson.internal.bind.DateTypeAdapter$1@153143f3, Factory[type=java.util.Calendar+java.util.GregorianCalendar,adapter=com.google.gson.internal.bind.TypeAdapters$27@6bf50d09], com.google.gson.internal.bind.TimeTypeAdapter$1@3e45ba8d, com.google.gson.internal.bind.SqlDateTypeAdapter$1@f262694, com.google.gson.internal.bind.TypeAdapters$26@1017c258, com.google.gson.internal.bind.ArrayTypeAdapter$1@53c90816, Factory[type=java.lang.Class,adapter=com.google.gson.TypeAdapter$1@40cb5130], com.google.gson.internal.bind.CollectionTypeAdapterFactory@7e67cd3b, com.google.gson.internal.bind.MapTypeAdapterFactory@504cd5ad, com.google.gson.internal.bind.JsonAdapterAnnotationTypeAdapterFactory@4b5efe0a, com.google.gson.internal.bind.TypeAdapters$30@51066480, com.google.gson.internal.bind.ReflectiveTypeAdapterFactory@11c8758e],instanceCreators:{}}, hostPort=localhost:5778), metrics=io.jaegertracing.internal.metrics.Metrics@279f3ba7, sampler=ProbabilisticSampler(positiveSamplingBoundary=9223372036854776, negativeSamplingBoundary=-9223372036854776, samplingRate=0.001, tags={sampler.type=probabilistic, sampler.param=0.001})), ipv4=2130706433, tags={hostname=rhel7-large-74052, jaeger.version=Java-0.30.4, ip=127.0.0.1}, zipkinSharedRpcSpan=false, baggageSetter=io.jaegertracing.internal.baggage.BaggageSetter@1b8d3ff0, expandExceptionLogs=false)
> {code}
> I think these messages are not useful on INFO level and should be lowered to either DEBUG or TRACE level.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10918) Server dependencies should not contain ironjacamar-spec-api
by Yeray Borges (JIRA)
Yeray Borges created WFLY-10918:
-----------------------------------
Summary: Server dependencies should not contain ironjacamar-spec-api
Key: WFLY-10918
URL: https://issues.jboss.org/browse/WFLY-10918
Project: WildFly
Issue Type: Task
Reporter: Yeray Borges
Assignee: Yeray Borges
We should exclude ironjacamar-spec-api artifact, It is not delivered in the server and it will help at productization level to build the server from the sources using only maven central and product repository.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10904) Lower logging level of messages for OpenTracing
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-10904?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFLY-10904:
------------------------------------
Just for a clarification - my point was not to remove DEBUG level log message. I just wanted to show that removing INFO level in this case actually does not remove any information as it is there still on DEBUG level. :)
Also, regarding to the log messages you mentioned in [one of your previous comment|https://issues.jboss.org/browse/WFLY-10904?focusedCommentId=13622...],
{code}
16:07:03,673 INFO [io.opentracing.contrib.jaxrs2.server.ServerTracingDynamicFeature] (ServerService Thread Pool -- 10) Registering tracing on deployed resources...
{code}
Is it still there? I think I cannot reproduce it via running the {{mvn test -Dtest=org.jboss.as.test.integration.microprofile.opentracing.**}} in {{testsuite/integration/basic}}.
> Lower logging level of messages for OpenTracing
> -----------------------------------------------
>
> Key: WFLY-10904
> URL: https://issues.jboss.org/browse/WFLY-10904
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> Current logging for OpenTracing is quite verbose logging long messages in INFO level, e.g.:
> {code}
> 17:38:45,359 INFO [io.jaegertracing.internal.senders.SenderResolver] (ServerService Thread Pool -- 28) Using sender UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0))
> 17:38:45,395 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 28) Initialized tracer=JaegerTracer(version=Java-0.30.4, serviceName=deployment.war, reporter=RemoteReporter(queueProcessor=RemoteReporter.QueueProcessor(open=true), sender=UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0)), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, serviceName=deployment.war, manager=HttpSamplingManager(gson={serializeNulls:false,factories:[Factory[typeHierarchy=com.google.gson.JsonElement,adapter=com.google.gson.internal.bind.TypeAdapters$29@5795d61d], com.google.gson.internal.bind.ObjectTypeAdapter$1@7286f924, com.google.gson.internal.Excluder@10bd7673, Factory[type=java.lang.String,adapter=com.google.gson.internal.bind.TypeAdapters$16@56577ab9], Factory[type=java.lang.Integer+int,adapter=com.google.gson.internal.bind.TypeAdapters$7@2f0b6b50], Factory[type=java.lang.Boolean+boolean,adapter=com.google.gson.internal.bind.TypeAdapters$3@6a01f84c], Factory[type=java.lang.Byte+byte,adapter=com.google.gson.internal.bind.TypeAdapters$5@11f41591], Factory[type=java.lang.Short+short,adapter=com.google.gson.internal.bind.TypeAdapters$6@7c9b37a4], Factory[type=java.lang.Long+long,adapter=com.google.gson.internal.bind.TypeAdapters$11@8be828c], Factory[type=java.lang.Double+double,adapter=com.google.gson.Gson$1@6d18d84f], Factory[type=java.lang.Float+float,adapter=com.google.gson.Gson$2@5c7110e0], Factory[type=java.lang.Number,adapter=com.google.gson.internal.bind.TypeAdapters$14@79f22add], Factory[type=java.util.concurrent.atomic.AtomicInteger,adapter=com.google.gson.TypeAdapter$1@5a47d8d], Factory[type=java.util.concurrent.atomic.AtomicBoolean,adapter=com.google.gson.TypeAdapter$1@2ed507d6], Factory[type=java.util.concurrent.atomic.AtomicLong,adapter=com.google.gson.TypeAdapter$1@7af7f4fc], Factory[type=java.util.concurrent.atomic.AtomicLongArray,adapter=com.google.gson.TypeAdapter$1@123b9dbd], Factory[type=java.util.concurrent.atomic.AtomicIntegerArray,adapter=com.google.gson.TypeAdapter$1@3455c262], Factory[type=java.lang.Character+char,adapter=com.google.gson.internal.bind.TypeAdapters$15@32b89889], Factory[type=java.lang.StringBuilder,adapter=com.google.gson.internal.bind.TypeAdapters$19@772dda36], Factory[type=java.lang.StringBuffer,adapter=com.google.gson.internal.bind.TypeAdapters$20@3935671b], Factory[type=java.math.BigDecimal,adapter=com.google.gson.internal.bind.TypeAdapters$17@23e9f48d], Factory[type=java.math.BigInteger,adapter=com.google.gson.internal.bind.TypeAdapters$18@55634ca9], Factory[type=java.net.URL,adapter=com.google.gson.internal.bind.TypeAdapters$21@4c06d059], Factory[type=java.net.URI,adapter=com.google.gson.internal.bind.TypeAdapters$22@5e997b7d], Factory[type=java.util.UUID,adapter=com.google.gson.internal.bind.TypeAdapters$24@3238a1bf], Factory[type=java.util.Currency,adapter=com.google.gson.TypeAdapter$1@7d71b555], Factory[type=java.util.Locale,adapter=com.google.gson.internal.bind.TypeAdapters$28@70f36ba], Factory[typeHierarchy=java.net.InetAddress,adapter=com.google.gson.internal.bind.TypeAdapters$23@12d8e7b5], Factory[type=java.util.BitSet,adapter=com.google.gson.TypeAdapter$1@659a9908], com.google.gson.internal.bind.DateTypeAdapter$1@153143f3, Factory[type=java.util.Calendar+java.util.GregorianCalendar,adapter=com.google.gson.internal.bind.TypeAdapters$27@6bf50d09], com.google.gson.internal.bind.TimeTypeAdapter$1@3e45ba8d, com.google.gson.internal.bind.SqlDateTypeAdapter$1@f262694, com.google.gson.internal.bind.TypeAdapters$26@1017c258, com.google.gson.internal.bind.ArrayTypeAdapter$1@53c90816, Factory[type=java.lang.Class,adapter=com.google.gson.TypeAdapter$1@40cb5130], com.google.gson.internal.bind.CollectionTypeAdapterFactory@7e67cd3b, com.google.gson.internal.bind.MapTypeAdapterFactory@504cd5ad, com.google.gson.internal.bind.JsonAdapterAnnotationTypeAdapterFactory@4b5efe0a, com.google.gson.internal.bind.TypeAdapters$30@51066480, com.google.gson.internal.bind.ReflectiveTypeAdapterFactory@11c8758e],instanceCreators:{}}, hostPort=localhost:5778), metrics=io.jaegertracing.internal.metrics.Metrics@279f3ba7, sampler=ProbabilisticSampler(positiveSamplingBoundary=9223372036854776, negativeSamplingBoundary=-9223372036854776, samplingRate=0.001, tags={sampler.type=probabilistic, sampler.param=0.001})), ipv4=2130706433, tags={hostname=rhel7-large-74052, jaeger.version=Java-0.30.4, ip=127.0.0.1}, zipkinSharedRpcSpan=false, baggageSetter=io.jaegertracing.internal.baggage.BaggageSetter@1b8d3ff0, expandExceptionLogs=false)
> {code}
> I think these messages are not useful on INFO level and should be lowered to either DEBUG or TRACE level.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10904) Lower logging level of messages for OpenTracing
by Juraci Paixão Kröhling (JIRA)
[ https://issues.jboss.org/browse/WFLY-10904?page=com.atlassian.jira.plugin... ]
Juraci Paixão Kröhling commented on WFLY-10904:
-----------------------------------------------
That's a good point. The reason it happens is because we allow applications to provide their own tracers, which the MP-OT subsystem logs as DEBUG level, whereas the other message is at the Jaeger level.
If we remove the debug level message, we'll be potentially be removing a valuable source of information to users who are deploying a custom tracer, which might be also a Jaeger tracer, with a different configuration.
IMO, we can live with that, as DEBUG does imply (to me) that the same info might be printed out at different layers.
> Lower logging level of messages for OpenTracing
> -----------------------------------------------
>
> Key: WFLY-10904
> URL: https://issues.jboss.org/browse/WFLY-10904
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> Current logging for OpenTracing is quite verbose logging long messages in INFO level, e.g.:
> {code}
> 17:38:45,359 INFO [io.jaegertracing.internal.senders.SenderResolver] (ServerService Thread Pool -- 28) Using sender UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0))
> 17:38:45,395 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 28) Initialized tracer=JaegerTracer(version=Java-0.30.4, serviceName=deployment.war, reporter=RemoteReporter(queueProcessor=RemoteReporter.QueueProcessor(open=true), sender=UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0)), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, serviceName=deployment.war, manager=HttpSamplingManager(gson={serializeNulls:false,factories:[Factory[typeHierarchy=com.google.gson.JsonElement,adapter=com.google.gson.internal.bind.TypeAdapters$29@5795d61d], com.google.gson.internal.bind.ObjectTypeAdapter$1@7286f924, com.google.gson.internal.Excluder@10bd7673, Factory[type=java.lang.String,adapter=com.google.gson.internal.bind.TypeAdapters$16@56577ab9], Factory[type=java.lang.Integer+int,adapter=com.google.gson.internal.bind.TypeAdapters$7@2f0b6b50], Factory[type=java.lang.Boolean+boolean,adapter=com.google.gson.internal.bind.TypeAdapters$3@6a01f84c], Factory[type=java.lang.Byte+byte,adapter=com.google.gson.internal.bind.TypeAdapters$5@11f41591], Factory[type=java.lang.Short+short,adapter=com.google.gson.internal.bind.TypeAdapters$6@7c9b37a4], Factory[type=java.lang.Long+long,adapter=com.google.gson.internal.bind.TypeAdapters$11@8be828c], Factory[type=java.lang.Double+double,adapter=com.google.gson.Gson$1@6d18d84f], Factory[type=java.lang.Float+float,adapter=com.google.gson.Gson$2@5c7110e0], Factory[type=java.lang.Number,adapter=com.google.gson.internal.bind.TypeAdapters$14@79f22add], Factory[type=java.util.concurrent.atomic.AtomicInteger,adapter=com.google.gson.TypeAdapter$1@5a47d8d], Factory[type=java.util.concurrent.atomic.AtomicBoolean,adapter=com.google.gson.TypeAdapter$1@2ed507d6], Factory[type=java.util.concurrent.atomic.AtomicLong,adapter=com.google.gson.TypeAdapter$1@7af7f4fc], Factory[type=java.util.concurrent.atomic.AtomicLongArray,adapter=com.google.gson.TypeAdapter$1@123b9dbd], Factory[type=java.util.concurrent.atomic.AtomicIntegerArray,adapter=com.google.gson.TypeAdapter$1@3455c262], Factory[type=java.lang.Character+char,adapter=com.google.gson.internal.bind.TypeAdapters$15@32b89889], Factory[type=java.lang.StringBuilder,adapter=com.google.gson.internal.bind.TypeAdapters$19@772dda36], Factory[type=java.lang.StringBuffer,adapter=com.google.gson.internal.bind.TypeAdapters$20@3935671b], Factory[type=java.math.BigDecimal,adapter=com.google.gson.internal.bind.TypeAdapters$17@23e9f48d], Factory[type=java.math.BigInteger,adapter=com.google.gson.internal.bind.TypeAdapters$18@55634ca9], Factory[type=java.net.URL,adapter=com.google.gson.internal.bind.TypeAdapters$21@4c06d059], Factory[type=java.net.URI,adapter=com.google.gson.internal.bind.TypeAdapters$22@5e997b7d], Factory[type=java.util.UUID,adapter=com.google.gson.internal.bind.TypeAdapters$24@3238a1bf], Factory[type=java.util.Currency,adapter=com.google.gson.TypeAdapter$1@7d71b555], Factory[type=java.util.Locale,adapter=com.google.gson.internal.bind.TypeAdapters$28@70f36ba], Factory[typeHierarchy=java.net.InetAddress,adapter=com.google.gson.internal.bind.TypeAdapters$23@12d8e7b5], Factory[type=java.util.BitSet,adapter=com.google.gson.TypeAdapter$1@659a9908], com.google.gson.internal.bind.DateTypeAdapter$1@153143f3, Factory[type=java.util.Calendar+java.util.GregorianCalendar,adapter=com.google.gson.internal.bind.TypeAdapters$27@6bf50d09], com.google.gson.internal.bind.TimeTypeAdapter$1@3e45ba8d, com.google.gson.internal.bind.SqlDateTypeAdapter$1@f262694, com.google.gson.internal.bind.TypeAdapters$26@1017c258, com.google.gson.internal.bind.ArrayTypeAdapter$1@53c90816, Factory[type=java.lang.Class,adapter=com.google.gson.TypeAdapter$1@40cb5130], com.google.gson.internal.bind.CollectionTypeAdapterFactory@7e67cd3b, com.google.gson.internal.bind.MapTypeAdapterFactory@504cd5ad, com.google.gson.internal.bind.JsonAdapterAnnotationTypeAdapterFactory@4b5efe0a, com.google.gson.internal.bind.TypeAdapters$30@51066480, com.google.gson.internal.bind.ReflectiveTypeAdapterFactory@11c8758e],instanceCreators:{}}, hostPort=localhost:5778), metrics=io.jaegertracing.internal.metrics.Metrics@279f3ba7, sampler=ProbabilisticSampler(positiveSamplingBoundary=9223372036854776, negativeSamplingBoundary=-9223372036854776, samplingRate=0.001, tags={sampler.type=probabilistic, sampler.param=0.001})), ipv4=2130706433, tags={hostname=rhel7-large-74052, jaeger.version=Java-0.30.4, ip=127.0.0.1}, zipkinSharedRpcSpan=false, baggageSetter=io.jaegertracing.internal.baggage.BaggageSetter@1b8d3ff0, expandExceptionLogs=false)
> {code}
> I think these messages are not useful on INFO level and should be lowered to either DEBUG or TRACE level.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months