[JBoss JIRA] (JGRP-1833) Add JAAS support to the SASL protocol
by Tristan Tarrant (JIRA)
Tristan Tarrant created JGRP-1833:
-------------------------------------
Summary: Add JAAS support to the SASL protocol
Key: JGRP-1833
URL: https://issues.jboss.org/browse/JGRP-1833
Project: JGroups
Issue Type: Feature Request
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 3.5
Add configuration options so that the SASL protocol can be given a client/server Subject or a JAAS LoginModule so that it can create the SaslClient/SaslServer with the correct security environment (required by GSSAPI).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBWEB-297:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1090103, https://bugzilla.redhat.com/show_bug.cgi?id=1093718 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1090103)
> NIO can improperly lead to request/response objects being used concurrently
> ---------------------------------------------------------------------------
>
> Key: JBWEB-297
> URL: https://issues.jboss.org/browse/JBWEB-297
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Attachments: JBWEB-297.diff
>
>
> Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises here in Http11NioProtocol.event():
> {code:title=Http11NioProtocol.java|borderStyle=solid}
> public SocketState event(NioChannel channel, SocketStatus status) {
> Http11NioProcessor processor = connections.get(channel.getId());
> SocketState state = SocketState.CLOSED;
> if (processor != null) {
> processor.startProcessing();
> // Call the appropriate event
> try {
> state = processor.event(status);
> } catch (java.net.SocketException e) {
> // SocketExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> } catch (java.io.IOException e) {
> // IOExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> }
> // Future developers: if you discover any other
> // rare-but-nonfatal exceptions, catch them here, and log as
> // above.
> catch (Throwable e) {
> // any other exception or error is odd. Here we log it
> // with "ERROR" level, so it will show up even on
> // less-than-verbose logs.
> CoyoteLogger.HTTP_NIO_LOGGER.socketError(e);
> } finally {
> if (state != SocketState.LONG) {
> connections.remove(channel.getId());
> recycledProcessors.offer(processor);
> {code}
> If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors.
> It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run().
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-3311) Intermittent connection TimeOut with CLI using https-remoting
by Filip Bogyai (JIRA)
Filip Bogyai created WFLY-3311:
----------------------------------
Summary: Intermittent connection TimeOut with CLI using https-remoting
Key: WFLY-3311
URL: https://issues.jboss.org/browse/WFLY-3311
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CLI
Affects Versions: 8.1.0.CR1
Reporter: Filip Bogyai
Assignee: Alexey Loubyansky
When the management http-interface is secured to use https and the CLI is using https-remoting to connect, sometimes it hangs which leads to connection timeout. This occurs approximately in 1 out of 10 times if you try to connect with CLI in a short time.
{code}
org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.modules.Module.run(Module.java:312)
at org.jboss.modules.Main.main(Main.java:460)
Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9993
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:840)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:819)
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276)
... 8 more
Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1005)
... 11 more
Caused by: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169)
at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
... 13 more
{code}
This problem also causes intermittent test failures in testsuite, for example:
http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI...
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer commented on DROOLS-471:
-----------------------------------------------
having build problems when removing dependencies in kie-wb-distributions/kie-eap-integration/kie-eap-modules/kie-jboss-eap-base-modules/jboss-eap-6.1.1/javax-security-jacc-api-main/pom.xml.
Try to sort this out.
> Remove repository jboss-deprecated
> ----------------------------------
>
> Key: DROOLS-471
> URL: https://issues.jboss.org/browse/DROOLS-471
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
> <repository>
> <id>jboss-deprecated</id>
> <name>JBoss Deprecated</name>
> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer commented on DROOLS-471:
-----------------------------------------------
speaking to Marko Rietveld: he takes care of droolsjbpm-integration/kie-remote/kie-services-remote/pom.xml
speaking to Roger, we agrred that the best is to remove the dependencies-
<!-- Custom dependencies. -->
<dependency>
<groupId>javax.security</groupId>
<artifactId>jacc</artifactId>
<version>1.0</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>javax.security.jacc</groupId>
<artifactId>javax.security.jacc-api</artifactId>
<version>1.4</version>
<type>jar</type>
</dependency>
in kie-wb-distributions/kie-eap-integration/kie-eap-modules/kie-jboss-eap-base-modules/jboss-eap-6.1.1/javax-security-jacc-api-main/pom.xml
I will do this.
> Remove repository jboss-deprecated
> ----------------------------------
>
> Key: DROOLS-471
> URL: https://issues.jboss.org/browse/DROOLS-471
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
> <repository>
> <id>jboss-deprecated</id>
> <name>JBoss Deprecated</name>
> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (DROOLS-476) NPE when MVEL parses arithmetic expression
by Hassler Jean-Christian (JIRA)
[ https://issues.jboss.org/browse/DROOLS-476?page=com.atlassian.jira.plugin... ]
Hassler Jean-Christian updated DROOLS-476:
------------------------------------------
Summary: NPE when MVEL parses arithmetic expression (was: NPE when parsing arithmetic expression)
> NPE when MVEL parses arithmetic expression
> ------------------------------------------
>
> Key: DROOLS-476
> URL: https://issues.jboss.org/browse/DROOLS-476
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: sun JDK 1.6;
> Drools 5.5.0Final
> Reporter: Hassler Jean-Christian
> Assignee: Mark Proctor
> Labels: mvel, parsing
>
> When user write computations with MVEL, mvel throw the error {color:red}[Error: not a statement, or badly formed structure] {color}at parsing time.
> If you add parenthesis, parsing is OK.
> The issue can be reproduced directly with the lastest MVEL version.
> As you can see in the test below, same expression with parenthesis is OK. Debugging into mvel engine shows that there some nullPointerException in the bad case.
> This issue was reproduced with the MVEL version embedded inside Drools 5.5.0Final and also with MVEL version 2.1.9.Final.
> {code:java}
> public class MvelTest {
> public void test(){
>
> String expressionThatDoesNotWork = "5 + 1/10 * (VAR - 5)"; // !!! mvel cannot parse this expression
> String expressionThatWorks = "5 + (1/10) * (VAR - 5)"; //with additionnal parenthesis it's OK
>
> Serializable parsingResultOK = MVEL.compileExpression(expressionThatWorks); //this works seamlessly
> System.out.println(parsingResultOK); //=> (Literal<5> + (Literal<0.1> * (VAR - Literal<5>)))
>
> Serializable failedResult = MVEL.compileExpression(expressionThatDoesNotWork); // !!! this throws NullPointerException in MVEL engine
>
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (DROOLS-476) NPE when parsing arithmetic expression
by Hassler Jean-Christian (JIRA)
Hassler Jean-Christian created DROOLS-476:
---------------------------------------------
Summary: NPE when parsing arithmetic expression
Key: DROOLS-476
URL: https://issues.jboss.org/browse/DROOLS-476
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Environment: sun JDK 1.6;
Drools 5.5.0Final
Reporter: Hassler Jean-Christian
Assignee: Mark Proctor
When user write computations with MVEL, mvel throw the error {color:red}[Error: not a statement, or badly formed structure] {color}at parsing time.
If you add parenthesis, parsing is OK.
The issue can be reproduced directly with the lastest MVEL version.
As you can see in the test below, same expression with parenthesis is OK. Debugging into mvel engine shows that there some nullPointerException in the bad case.
This issue was reproduced with the MVEL version embedded inside Drools 5.5.0Final and also with MVEL version 2.1.9.Final.
{code:java}
public class MvelTest {
public void test(){
String expressionThatDoesNotWork = "5 + 1/10 * (VAR - 5)"; // !!! mvel cannot parse this expression
String expressionThatWorks = "5 + (1/10) * (VAR - 5)"; //with additionnal parenthesis it's OK
Serializable parsingResultOK = MVEL.compileExpression(expressionThatWorks); //this works seamlessly
System.out.println(parsingResultOK); //=> (Literal<5> + (Literal<0.1> * (VAR - Literal<5>)))
Serializable failedResult = MVEL.compileExpression(expressionThatDoesNotWork); // !!! this throws NullPointerException in MVEL engine
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski commented on WFLY-3197:
------------------------------------------
Only in case that there are no env/static/class name clash between AS7/8 modules and external context module.
> ExternalContextFactory cuts context from deployment context/requires dependency on module
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3197
> URL: https://issues.jboss.org/browse/WFLY-3197
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Fix For: 8.1.0.Final
>
>
> WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found.
> Steps to reproduce:
> 1. define isolated module IM ( with classloader IM_CL )
> 2. create external-context-factory with module set to IM
> 3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies
> 4. lookup and invoke proxy
> Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing.
> Case 1: application and custom context dont do CCL magic
> - invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found )
> Case 2: application or custom context switch CCL to IM_CL for lookup
> - CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably
> Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL.
> Workaround:
> yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation.
> Possible fix:
> 1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic
> 2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (DROOLS-475) Drools condition part always use MVEL strict mode (extended classes doen't get properties of super class )
by Shailesh T (JIRA)
[ https://issues.jboss.org/browse/DROOLS-475?page=com.atlassian.jira.plugin... ]
Shailesh T updated DROOLS-475:
------------------------------
Description:
Even after setting MVEL strict mode to false, condition part of drools works using strict mode and can't work with Inherited getters of HashMap (Breaks lot of working rules from 5.4)
Error: [Error: unable to resolve method using strict-mode: defaultpkg.Test.Price()]
[Near : {... Price < 100 ....}]
...
t: HashMap(
Price < 11
)
..
Does work but
import java.util.HashMap;
declare HashMap
end
declare Test extends HashMap
end
t: Test(
Price<100
)
doesn't work (please see full rules in steps to reproduce)
Even condition
this["OtherPrices"]["OldPrice"] < 9
does work for Map but not for inherited Test class
(applicable but not included in sample code to reproduce issue, added drl for this as attachment)
was:
Even after setting MVEL strict mode to false, condition part of drools works using strict mode and can't work with Inherited getters of HashMap (Breaks lot of working rules from 5.4)
Error: [Error: unable to resolve method using strict-mode: defaultpkg.Test.Price()]
[Near : {... Price < 100 ....}]
...
t: HashMap(
Price < 11
)
..
Does work but
import java.util.HashMap;
declare HashMap
end
declare Test extends HashMap
end
t: Test(
Price<100
)
doesn't work (please see full rules in steps to reproduce)
Even condition
this["OtherPrices"]["OldPrice"] < 9
does work for Map but not for inherited Test class
(applicable but not included in sample code to reproduce issue)
> Drools condition part always use MVEL strict mode (extended classes doen't get properties of super class )
> ----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-475
> URL: https://issues.jboss.org/browse/DROOLS-475
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: JDK 6, MVEL as default, with strict-mode set to false with file META-INF/drools.default.packagebuilder.conf with following entries
> drools.dialect.default = mvel
> drools.dialect.java = org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration
> drools.dialect.java.compiler = ECLIPSE
> drools.dialect.mvel = org.drools.compiler.rule.builder.dialect.mvel.MVELDialectConfiguration
> drools.dialect.mvel.strict = false
> Reporter: Shailesh T
> Assignee: Mark Proctor
> Priority: Critical
> Labels: drools, mvel, strict-mode
> Attachments: BasicInclude.drl
>
>
> Even after setting MVEL strict mode to false, condition part of drools works using strict mode and can't work with Inherited getters of HashMap (Breaks lot of working rules from 5.4)
> Error: [Error: unable to resolve method using strict-mode: defaultpkg.Test.Price()]
> [Near : {... Price < 100 ....}]
> ...
> t: HashMap(
> Price < 11
> )
> ..
> Does work but
> import java.util.HashMap;
> declare HashMap
> end
> declare Test extends HashMap
> end
> t: Test(
> Price<100
> )
> doesn't work (please see full rules in steps to reproduce)
> Even condition
> this["OtherPrices"]["OldPrice"] < 9
> does work for Map but not for inherited Test class
> (applicable but not included in sample code to reproduce issue, added drl for this as attachment)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (DROOLS-475) Drools condition part always use MVEL strict mode (extended classes doen't get properties of super class )
by Shailesh T (JIRA)
[ https://issues.jboss.org/browse/DROOLS-475?page=com.atlassian.jira.plugin... ]
Shailesh T updated DROOLS-475:
------------------------------
Attachment: BasicInclude.drl
> Drools condition part always use MVEL strict mode (extended classes doen't get properties of super class )
> ----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-475
> URL: https://issues.jboss.org/browse/DROOLS-475
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: JDK 6, MVEL as default, with strict-mode set to false with file META-INF/drools.default.packagebuilder.conf with following entries
> drools.dialect.default = mvel
> drools.dialect.java = org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration
> drools.dialect.java.compiler = ECLIPSE
> drools.dialect.mvel = org.drools.compiler.rule.builder.dialect.mvel.MVELDialectConfiguration
> drools.dialect.mvel.strict = false
> Reporter: Shailesh T
> Assignee: Mark Proctor
> Priority: Critical
> Labels: drools, mvel, strict-mode
> Attachments: BasicInclude.drl
>
>
> Even after setting MVEL strict mode to false, condition part of drools works using strict mode and can't work with Inherited getters of HashMap (Breaks lot of working rules from 5.4)
> Error: [Error: unable to resolve method using strict-mode: defaultpkg.Test.Price()]
> [Near : {... Price < 100 ....}]
> ...
> t: HashMap(
> Price < 11
> )
> ..
> Does work but
> import java.util.HashMap;
> declare HashMap
> end
> declare Test extends HashMap
> end
> t: Test(
> Price<100
> )
> doesn't work (please see full rules in steps to reproduce)
> Even condition
> this["OtherPrices"]["OldPrice"] < 9
> does work for Map but not for inherited Test class
> (applicable but not included in sample code to reproduce issue)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months