[JBoss JIRA] (ISPN-7583) ClusterListenerDistInitialStateTest.testPrimaryOwnerGoesDownBeforeSendingEvent random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7583?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7583:
----------------------------------
Fix Version/s: 9.0.0.CR4
> ClusterListenerDistInitialStateTest.testPrimaryOwnerGoesDownBeforeSendingEvent random failures
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-7583
> URL: https://issues.jboss.org/browse/ISPN-7583
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
> Fix For: 9.0.0.CR4
>
>
> fixes:
> {code:java}
> testPrimaryOwnerGoesDownBeforeSendingEvent(org.infinispan.notifications.cachelistener.cluster.ClusterListenerDistInitialStateTest) Time elapsed: 0.015 sec <<< FAILURE!
> java.lang.AssertionError: expected [ClusterListenerDistInitialStateTest-NodeDR-44410] but found [ClusterListenerDistInitialStateTest-NodeDP-19475]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:165)
> at org.infinispan.notifications.cachelistener.cluster.ClusterListenerDistTest.testPrimaryOwnerGoesDownBeforeSendingEvent(ClusterListenerDistTest.java:74)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7656) DefaultDataContainer.entrySet().stream().toArray(Object[]::new) may fail
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7656?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-7656:
-------------------------------------
Okay the issue is the IteratorSpliterator marks the Spliterator as SIZED if the spliterator wasn't also CONCURRENT. So I just added an override for spliterator method telling them it is a DISTINCT and CONCURRENT spliterator. I will also add for the values collection. The keyset collection is fine as it is using the a copy anyways.
> DefaultDataContainer.entrySet().stream().toArray(Object[]::new) may fail
> ------------------------------------------------------------------------
>
> Key: ISPN-7656
> URL: https://issues.jboss.org/browse/ISPN-7656
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Radim Vansa
> Assignee: William Burns
>
> When the default Spliterator estimates size of the array, it calls {{DefaultDataContainer.EntrySet#size()}} that returns directly the size of container (including expired entries). Then the container is iterated using {{ImmutableEntryIterator}} which excludes expired entries by default, and this may return less elements than the original size() provided. That causes failure like this:
> {code}
> java.lang.IllegalStateException: End size 1 is less than fixed size 2
> at java.util.stream.Nodes$FixedNodeBuilder.end(Nodes.java:1232)
> at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> {code}
> Note that this can also happen without expiration upon concurrent modification. We have to adjust the characteristics (remove {{#SIZED}}) of provided spliterators.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7656) DefaultDataContainer.entrySet().stream().toArray(Object[]::new) may fail
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7656?page=com.atlassian.jira.plugin.... ]
Work on ISPN-7656 started by William Burns.
-------------------------------------------
> DefaultDataContainer.entrySet().stream().toArray(Object[]::new) may fail
> ------------------------------------------------------------------------
>
> Key: ISPN-7656
> URL: https://issues.jboss.org/browse/ISPN-7656
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Radim Vansa
> Assignee: William Burns
>
> When the default Spliterator estimates size of the array, it calls {{DefaultDataContainer.EntrySet#size()}} that returns directly the size of container (including expired entries). Then the container is iterated using {{ImmutableEntryIterator}} which excludes expired entries by default, and this may return less elements than the original size() provided. That causes failure like this:
> {code}
> java.lang.IllegalStateException: End size 1 is less than fixed size 2
> at java.util.stream.Nodes$FixedNodeBuilder.end(Nodes.java:1232)
> at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> {code}
> Note that this can also happen without expiration upon concurrent modification. We have to adjust the characteristics (remove {{#SIZED}}) of provided spliterators.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7586) Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7586?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7586:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.CR4
Resolution: Done
> Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies
> ----------------------------------------------------------------------------------
>
> Key: ISPN-7586
> URL: https://issues.jboss.org/browse/ISPN-7586
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.0.0.CR4
>
>
> We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster.
> This cause situations like this in the client:
> {code:java}
> client.put("K","value")
> // will get "V" back
> client.get("K")
> // Deletes will not propagate to the source cluster,
> // the RemoteStore is in 'read-only' mode.
> client.remove("K")
> // Returns "V". Although deleted, value will be retrieved
> // from the remote store
> cache.get("K")
>
> {code}
> This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in read only mode, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7644) Administration console - Loader tab allows invalid configuration to be set.
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7644?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reopened ISPN-7644:
--------------------------------
> Administration console - Loader tab allows invalid configuration to be set.
> ---------------------------------------------------------------------------
>
> Key: ISPN-7644
> URL: https://issues.jboss.org/browse/ISPN-7644
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> Click on cache container -> cache -> configuration -> loader tab
> Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "clustered"),
> ("configurations" => "CONFIGURATIONS"),
> ("distributed-cache-configuration" => "distributedCache")
> ]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
> Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
> I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7644) Administration console - Loader tab allows invalid configuration to be set.
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7644?page=com.atlassian.jira.plugin.... ]
Ryan Emerson edited comment on ISPN-7644 at 3/22/17 1:40 PM:
-------------------------------------------------------------
[~rmacor] This is actually a limitation of using the `<loader class=""/>` syntax, which is what the loaders configuration tab exposes. It won't work properly for any of the included cache-stores as they are not listed as a dependency in `modules/system/layers/base/org/infinispan/main/module.xml`. File-store is the exception, as it is included in core.
Furthermore, stores configured via <loader/> don't have additional dependencies (e.g. JDBC datasources) loaded and the user is required to configure these properties for a working store anyway.
Users who need to utilise one of the built in cache stores purely as a loader, should use the "stores" tab and configure their desired store as "read-only". I propose that we remove all of the loader options from the dropdown menu, except "No cache loader", "Cluster Loader" and "Custom Loader".
[~vblagojevic], [~NadirX] WDYT?
was (Author: ryanemerson):
[~rmacor] This is actually a limitation of using the `<loader class=""/>` syntax, which is what the loaders configuration tab exposes. It won't work properly for any of the included cache-stores as they are not listed as a dependency in `modules/system/layers/base/org/infinispan/main/module.xml`. File-store is the exception, as it is included in core.
Furthermore, stores configured via <loader/> don't have additional dependencies (e.g. JDBC datasources) loaded and the user is required to configure these properties for a working store anyway.
Users who need to utilise one of the built in cache stores purely as a loader, should use the "stores" tab and configure their desired store as "read-only". I propose that we remove all of the loader options from the dropdown menu, except "No cache loader", "Cluster Loader" and "Custom Loader".
[~vblagojevic][~NadirX] WDYT?
> Administration console - Loader tab allows invalid configuration to be set.
> ---------------------------------------------------------------------------
>
> Key: ISPN-7644
> URL: https://issues.jboss.org/browse/ISPN-7644
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> Click on cache container -> cache -> configuration -> loader tab
> Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "clustered"),
> ("configurations" => "CONFIGURATIONS"),
> ("distributed-cache-configuration" => "distributedCache")
> ]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
> Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
> I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7644) Administration console - Loader tab allows invalid configuration to be set.
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7644?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on ISPN-7644:
------------------------------------
[~rmacor] This is actually a limitation of using the `<loader class=""/>` syntax, which is what the loaders configuration tab exposes. It won't work properly for any of the included cache-stores as they are not listed as a dependency in `modules/system/layers/base/org/infinispan/main/module.xml`. File-store is the exception, as it is included in core.
Furthermore, stores configured via <loader/> don't have additional dependencies (e.g. JDBC datasources) loaded and the user is required to configure these properties for a working store anyway.
Users who need to utilise one of the built in cache stores purely as a loader, should use the "stores" tab and configure their desired store as "read-only". I propose that we remove all of the loader options from the dropdown menu, except "No cache loader", "Cluster Loader" and "Custom Loader".
[~vblagojevic][~NadirX] WDYT?
> Administration console - Loader tab allows invalid configuration to be set.
> ---------------------------------------------------------------------------
>
> Key: ISPN-7644
> URL: https://issues.jboss.org/browse/ISPN-7644
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> Click on cache container -> cache -> configuration -> loader tab
> Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "clustered"),
> ("configurations" => "CONFIGURATIONS"),
> ("distributed-cache-configuration" => "distributedCache")
> ]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
> Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
> I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7635) ComponentMetadataPersister hangs with IBM JDK
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7635?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7635:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.CR4
Resolution: Done
> ComponentMetadataPersister hangs with IBM JDK
> ---------------------------------------------
>
> Key: ISPN-7635
> URL: https://issues.jboss.org/browse/ISPN-7635
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 9.0.0.CR3
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.CR4, 9.0.0.Final
>
>
> When building with IBM JDK, the ComponentMetadataPersister hangs when generating infinispan-core's metadata:
> [08:24:58]W: [Step 1/2] [WARNING] Couldn't destroy threadgroup org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=org.infinispan.factories.components.ComponentMetadataPersister,maxpri=10]
> [08:24:58] : [Step 1/2] java.lang.IllegalThreadStateException: Has threads
> [08:24:58] : [Step 1/2] at java.lang.ThreadGroup.destroyImpl(ThreadGroup.java:256)
> [08:24:58] : [Step 1/2] at java.lang.ThreadGroup.destroy(ThreadGroup.java:238)
> [08:24:58] : [Step 1/2] at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:328)
> [08:24:58] : [Step 1/2] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [08:24:58] : [Step 1/2] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> [08:24:58] : [Step 1/2] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> [08:24:58] : [Step 1/2] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> [08:24:58] : [Step 1/2] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> [08:24:58] : [Step 1/2] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [08:24:58] : [Step 1/2] at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> [08:24:58] : [Step 1/2] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [08:24:58] : [Step 1/2] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> [08:24:58] : [Step 1/2] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> [08:24:58] : [Step 1/2] at java.lang.reflect.Method.invoke(Method.java:507)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> After some investigation, it appears this is caused by log4j being on the classpath, pulled in as an optional compile dependency on infinispan-core.
> Since nothing on core depends on log4j the fix is to make the dependency scoped to test.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7655) Calling Primitives.writeRawPrimitive with char raises java.lang.ClassCastException
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7655?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7655:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.CR4
(was: 9.0.0.Final)
Resolution: Done
> Calling Primitives.writeRawPrimitive with char raises java.lang.ClassCastException
> ----------------------------------------------------------------------------------
>
> Key: ISPN-7655
> URL: https://issues.jboss.org/browse/ISPN-7655
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.CR3
> Environment: Found the problem with a unit test on vertx-infinispan projet that was failing
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Fix For: 9.0.0.CR4
>
>
> java.lang.ClassCastException: java.lang.Character cannot be cast to java.lang.Integer
> at org.infinispan.marshall.core.Primitives.writeRawPrimitive(Primitives.java:89)
> at org.infinispan.marshall.core.Primitives.writePrimitive(Primitives.java:71)
> at org.infinispan.marshall.core.JBossMarshallerTest.testTT(JBossMarshallerTest.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
> at org.testng.SuiteRunner.run(SuiteRunner.java:254)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:72)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:127)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years