[JBoss JIRA] (JGRP-2082) Coordinator failover is taking longer because VERIFY_SUSPECT runs twice
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-2082?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-2082:
-----------------------------------------------
Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1348404|https://bugzilla.redhat.com/show_bug.cgi?id=1348404] from MODIFIED to ON_QA
> Coordinator failover is taking longer because VERIFY_SUSPECT runs twice
> -----------------------------------------------------------------------
>
> Key: JGRP-2082
> URL: https://issues.jboss.org/browse/JGRP-2082
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.3
> Reporter: Osamu Nagano
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> There are 4 machines (m03, ..., m06) and 7 nodes (n001, ..., n007) on each. To test the coordinator failover behaviour, nodes on m03 are all killed at the same time. These are suspected and verified in sequence at the first time (line 9 to 18, only m03_n007 is verified as dead and others are just queued), while these are verified as a whole at the second time (line 19 to 34). Since the coordinator is in the queued at the first time, view change is not triggered and causing a delay.
> - m03_n001 is the original coordinator.
> - m05_n001 is the next coordinator and the owner of the following log messages.
> {code}
> 8 12:04:10,997 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK acceptor,m05_n001/clustered) m05_n001/clustered: accepted connection from /172.20.66.36:29702
> 9 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n001/clustered]
> 10 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n002/clustered]
> 11 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n003/clustered]
> 12 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n004/clustered]
> 13 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n005/clustered]
> 14 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n006/clustered]
> 15 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n007/clustered]
> 16 12:04:10,999 DEBUG [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: suspecting [m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n005/clustered, m03_n006/clustered, m03_n007/clustered]
> 17 12:04:11,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n007/clustered is dead
> 18 12:04:12,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n007/clustered is dead (passing up SUSPECT event)
> 19 12:04:16,000 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n003/clustered, m03_n004/clustered, m03_n005/clustered, m03_n002/clustered, m03_n001/clustered, m03_n007/clustered, m03_n006/clustered]
> 20 12:04:16,000 DEBUG [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: suspecting [m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n005/clustered, m03_n006/clustered, m03_n007/clustered]
> 21 12:04:16,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n003/clustered is dead
> 22 12:04:16,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n004/clustered is dead
> 23 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n005/clustered is dead
> 24 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n002/clustered is dead
> 25 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n001/clustered is dead
> 26 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n007/clustered is dead
> 27 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n006/clustered is dead
> 28 12:04:17,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n003/clustered is dead (passing up SUSPECT event)
> 29 12:04:17,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n004/clustered is dead (passing up SUSPECT event)
> 30 12:04:17,002 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n007/clustered is dead (passing up SUSPECT event)
> 31 12:04:17,002 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n001/clustered is dead (passing up SUSPECT event)
> 32 12:04:17,002 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n002/clustered is dead (passing up SUSPECT event)
> 33 12:04:17,003 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n005/clustered is dead (passing up SUSPECT event)
> 34 12:04:17,003 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n006/clustered is dead (passing up SUSPECT event)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2014) FILE_PING destination file name can include File.separator characters
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-2014?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-2014:
-----------------------------------------------
Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1306389|https://bugzilla.redhat.com/show_bug.cgi?id=1306389] from MODIFIED to ON_QA
> FILE_PING destination file name can include File.separator characters
> ---------------------------------------------------------------------
>
> Key: JGRP-2014
> URL: https://issues.jboss.org/browse/JGRP-2014
> Project: JGroups
> Issue Type: Bug
> Reporter: Alan Field
> Assignee: Bela Ban
> Fix For: 3.6.8, 4.0
>
>
> I was attempting to use FILE_PING as the discovery protocol with Infinispan server and the following configuration:
> {noformat}
> <protocol type="FILE_PING">
> <property name="location">${jgroups.file.dir:/Users/afield/Documents}</property>
> </protocol>
> {noformat}
> However, the following exceptions occur when I try to start the server:
> {noformat}
> 15:34:41,662 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-11) ISPN000078: Starting JGroups Channel
> 15:34:41,675 ERROR [org.jgroups.protocols.FILE_PING] (MSC service thread 1-11) attempt to write data failed at clustered : clustered.list: java.io.FileNotFoundException: /Users/afield/Documents/clustered/3e5f03c6-c297-474a-cb72-1ca0841f8e5c.afield-osx/clustered.list (No such file or directory)
> at java.io.FileOutputStream.open0(Native Method) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.open(FileOutputStream.java:270) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:213) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:162) [rt.jar:1.8.0_72]
> at org.jgroups.protocols.FILE_PING.write(FILE_PING.java:294) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FILE_PING.findMembers(FILE_PING.java:116) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:240) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.Discovery.down(Discovery.java:380) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:107) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.MERGE3.down(MERGE3.java:255) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:360) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:589) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:669) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:76) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1087) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:353) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.down(JChannel.java:791) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel._connect(JChannel.java:564) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.connect(JChannel.java:294) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.connect(JChannel.java:279) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:208) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:199) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_72]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_72]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_72]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_72]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:176) [infinispan-commons-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:238) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:583) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:549) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:420) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:434) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:105) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:102) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.security.Security.doPrivileged(Security.java:76) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:49) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:110) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:85) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_72]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_72]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_72]
> {noformat}
> From looking at the code, FILE_PING creates the {{/Users/afield/Documents/clustered}} directory, but the problem is that the {{local_addr}} for the host is {{afield-osx/clustered}}, so {{destination}} is defined as {{75b5c5b8-014d-26ff-c400-5398a96ad3f4.afield-osx/clustered.list}} when {{addressToFilename()}} is called and then the subsequent write fails. File.separator need to be removed or replaced in the {{destination}} variable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-609) Unguarded read in ElytronPolicyConfiguration
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-609:
---------------------------------
This one seems nontrivial because more than one lock is used to mediate access, which is almost certainly wrong.
> Unguarded read in ElytronPolicyConfiguration
> --------------------------------------------
>
> Key: ELY-609
> URL: https://issues.jboss.org/browse/ELY-609
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta7
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: static_analysis
> Fix For: 1.1.0.Beta8
>
>
> Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-611) Unintentional integer overflow in LongNameSetPermissionCollection
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-611?page=com.atlassian.jira.plugin.sy... ]
David Lloyd reassigned ELY-611:
-------------------------------
Assignee: David Lloyd (was: Darran Lofthouse)
> Unintentional integer overflow in LongNameSetPermissionCollection
> -----------------------------------------------------------------
>
> Key: ELY-611
> URL: https://issues.jboss.org/browse/ELY-611
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta7
> Reporter: Ondrej Lukas
> Assignee: David Lloyd
> Labels: static_analysis
> Fix For: 1.1.0.Beta8
>
>
> There are potentially overflowing expressions in org.wildfly.security.permission.LongNameSetPermissionCollection in {{getBitsForName}} method. Expressions {{1 << nameEnumeration.size()}} and {{1 << nameEnumeration.indexOf(name)}} are evaluated as integer but assigned to {{bits}} variable which is long. It can be avoided by casting {{1}} to long.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-615) Improvement for usage of file.mkdirs() in FileSystemSecurityRealm.Identity
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-615?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-615.
-----------------------------
Resolution: Rejected
This one is not a bug, but was deliberate, and the reason is that there are only three possible outcomes to this operation:
# The directory is created - in this case everything is fine
# The directory already exists - in this case everything is still fine
# The directory doesn't exist but can't be created for some reason - in this case the subsequent file operation will fail
Because 2 & 3 cannot be distinguished reliably, it's better to just defer until the filesystem operation.
> Improvement for usage of file.mkdirs() in FileSystemSecurityRealm.Identity
> --------------------------------------------------------------------------
>
> Key: ELY-615
> URL: https://issues.jboss.org/browse/ELY-615
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta7
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Minor
> Labels: static_analysis
> Fix For: 1.1.0.Beta8
>
>
> There is method {{tempPath()}} in org.wildfly.security.auth.realm.FileSystemSecurityRealm.Identity which uses {{file.mkdirs()}} without checking its return value. It is bad practice to ignore return value of this method (since false means that file has not been created and it can result to any unexpected and confusing failure later).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1242) built-in accumulate functions shall ignore NULLs
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1242:
--------------------------------------
Summary: built-in accumulate functions shall ignore NULLs
Key: DROOLS-1242
URL: https://issues.jboss.org/browse/DROOLS-1242
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Priority: Optional
This is a spin-off out of another problem [here|https://issues.jboss.org/browse/GUVNOR-2589?focusedCommentId=1326892...] for a proposal of improvement.
It could actually be beneficial for built-in accumulate functions to ignore NULLs.
This would be similar behavior of other languages such:
* SQL (e.g.: MySQL, Oracle, ..)
* Clojure
Currently it is up to the rule author to put a guarding condition in the first accumulate {{<source pattern>}} to manually ignore null sources to avoid the built-in accumulate functions to ignore NULLs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months