[JBoss JIRA] (ISPN-3454) Hot Rod client doesn't retry operation on RemoteException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3454?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3454:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1002957|https://bugzilla.redhat.com/show_bug.cgi?id=1002957] from ASSIGNED to ON_QA
> Hot Rod client doesn't retry operation on RemoteException
> ---------------------------------------------------------
>
> Key: ISPN-3454
> URL: https://issues.jboss.org/browse/ISPN-3454
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha3
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> This is a client-side problem.
> In a resilience test with 4 nodes where 1 is killed, I'm getting a lot of these:
> {code}
> 08:30:55,198 ERROR [org.jboss.smartfrog.jdg.loaddriver.DriverThread] (DriverThread-369) Error doing: PUT key399869 to node node04, took 493 ms
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[821188] returned server error (status=0x85): org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node01/default, see cause for remote stack trace
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:209)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at org.jboss.qa.jdg.adapter.Infinispan60Adapter$HotRodRemoteCacheAdapter.put(Infinispan60Adapter.java:269)
> at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.makeRequest(DriverThreadImpl.java:265)
> at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.run(DriverThreadImpl.java:378)
> {code}
> Isn't this a recoverable problem that shouldn't be left to user to handle ?
> source:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3601) REST cache store has problems with modules and finding classes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3601?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3601:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1006281|https://bugzilla.redhat.com/show_bug.cgi?id=1006281] from NEW to ON_QA
> REST cache store has problems with modules and finding classes
> --------------------------------------------------------------
>
> Key: ISPN-3601
> URL: https://issues.jboss.org/browse/ISPN-3601
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Alpha4
> Reporter: William Burns
> Assignee: William Burns
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> Found in DR4 as the first release which contains Infinispan 6.0.0.Aplha4 and therefore REST Cache Store + possibility of REST Rolling Upgrades.
> I've experienced problems with starting JDG node using standalone-rest-rolling-upgrade.xml example configuration (for target node).
> Please see report in attachment.
> You can find 2 console outputs of jdg server. The second one is after some changes in modules.xml (in rest cachestore module).
> Details are shown and described in that file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3376) CLI upgrade command does not work
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3376?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3376:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 989970|https://bugzilla.redhat.com/show_bug.cgi?id=989970] from ASSIGNED to ON_QA
> CLI upgrade command does not work
> ---------------------------------
>
> Key: ISPN-3376
> URL: https://issues.jboss.org/browse/ISPN-3376
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 6.0.0.Alpha1
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Labels: 620
> Fix For: 6.1.0.Final
>
> Attachments: logs.zip, standalone-hotrod-rolling-upgrade.xml
>
>
> Run my backup server with default standalone.xml configuration
> ./standalone.sh -c standalone.xml -Djboss.socket.binding.port-offset=111 -Djboss.node.name=BACKUPER
> Run my new server with
> ./standalone.sh -c standalone-hotrod-rolling-upgrade.xml -Djboss.node.name=UPGRADER
> 1) run command on BACKUPER
> [remoting://localhost:10110/local/default]> upgrade --dumpkeys default
> ISPN019502: Dumped keys for cache default
> 2) run command on UPGRADER
> [remoting://localhost:9999/local/default]> upgrade --synchronize=hotrod default
> ISPN019026: An error occurred while synchronizing data for cache 'hotrod' using migrator 'default' from the source server
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3270) Hotrod clients removeWithVersion doesn't work with replicated cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3270?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3270:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 987440|https://bugzilla.redhat.com/show_bug.cgi?id=987440] from ASSIGNED to ON_QA
> Hotrod clients removeWithVersion doesn't work with replicated cache
> -------------------------------------------------------------------
>
> Key: ISPN-3270
> URL: https://issues.jboss.org/browse/ISPN-3270
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 6.0.0.Beta1
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 620
> Attachments: server-trace-logs.zip
>
>
> I have a cluster of 2 latest infinispan servers (6.0.0-SNAPSHOT) with the following container configuration:
> {code:xml}<cache-container name="default" default-cache="default" listener-executor="infinispan-listener">
> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/>
> <replicated-cache name="default" start="EAGER" mode="SYNC" batching="false" remote-timeout="60000">
> <transaction mode="NONE"/>
> <state-transfer enabled="true" timeout="60000"/>
> </replicated-cache>
> </cache-container>
> {code}
> Running this code:
> {code} remoteCache = remoteCacheManager.getCache();
> remoteCache.clear();
> assertFalse(remoteCache.removeWithVersion("aKey", 12321212l));
> remoteCache.put("aKey", "aValue");
> VersionedValue valueBinary = remoteCache.getVersioned("aKey");
> System.out.println("value = " + valueBinary.getValue());
> System.out.println("version = " + valueBinary.getVersion());
> System.out.println(remoteCache.removeWithVersion("aKey",valueBinary.getVersion()));
> valueBinary = remoteCache.getVersioned("aKey");
> System.out.println("value = " + valueBinary.getValue());
> System.out.println("version = " + valueBinary.getVersion());
> {code}
> results most of the time in (and the other times the removeWithVersion returns false)
> {quote}
> value = aValue
> version = 281483566645249
> true
> value = aValue
> version = 281483566645249
> {quote}
> The command works with distributed/local cache.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3633:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1019348|https://bugzilla.redhat.com/show_bug.cgi?id=1019348] from POST to ON_QA
> InvalidateL1Command during ST should not cancel writing the entry by ST
> -----------------------------------------------------------------------
>
> Key: ISPN-3633
> URL: https://issues.jboss.org/browse/ISPN-3633
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.3.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry.
> Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3704:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1032050
> StateTransfer's PutKeyValueCommand may trigger remote get
> ---------------------------------------------------------
>
> Key: ISPN-3704
> URL: https://issues.jboss.org/browse/ISPN-3704
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
>
> In TX mode with write skew check on, ST executing puts may trigger a remote get.
> The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from
> {code}
> if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> to
> {code}
> if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3704:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1032050|https://bugzilla.redhat.com/show_bug.cgi?id=1032050]
In TX mode with write skew check on, ST executing puts may trigger a remote get.
This results in increased entry processing time during ST and possible failure in retrieving the value may lead to failed transaction -> lost entry on this node.
> StateTransfer's PutKeyValueCommand may trigger remote get
> ---------------------------------------------------------
>
> Key: ISPN-3704
> URL: https://issues.jboss.org/browse/ISPN-3704
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
>
> In TX mode with write skew check on, ST executing puts may trigger a remote get.
> The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from
> {code}
> if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> to
> {code}
> if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3712) HotRod Rolling Upgrades from Delirium 5.2.4 to latest server needs dropped org.infinispan.util.ByteArrayKey
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3712?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3712:
-----------------------------------------------
Tomas Sykora <tsykora(a)redhat.com> made a comment on [bug 1030485|https://bugzilla.redhat.com/show_bug.cgi?id=1030485]
But now, with one line lower (of course, import org.infinispan.util.ByteArrayKey; was added):
Caused by: java.lang.ClassNotFoundException: org.infinispan.util.ByteArrayKey from [Module "org.infinispan:main" from local module loader @284bd160 (finder: local module finder @99f0a4b (roots: /home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules,/home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:947)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1259)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:777)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:656)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:140)
at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:118)
at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.synchronizeData(HotRodTargetMigrator.java:62)
... 15 more
> HotRod Rolling Upgrades from Delirium 5.2.4 to latest server needs dropped org.infinispan.util.ByteArrayKey
> -----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3712
> URL: https://issues.jboss.org/browse/ISPN-3712
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Environment: Processing HotRod rolling upgrades from source Infinispan 'Delirium' 5.2.4.Final-redhat-1 server to the latest Infinispan 'Infinium' 6.0.0-SNAPSHOT. Using old standalone.xml for source node and examples/standalone-hotrod-rolling-upgrade.xml for new target server.
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
>
> When it is running from 6.0.0-SNAPSHOT to 6.0.0-SNAPSHOT it is ok. It looks like some back-porting compatibility issue.
> See stacktrace:
> javax.management.MBeanException
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:273)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:915)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.reflect.InvocationTargetException
> 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:601)
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271)
> ... 9 more
> Caused by: org.infinispan.commons.CacheException: java.lang.ClassNotFoundException: org.infinispan.util.ByteArrayKey from [Module "org.infinispan:main" from local module loader @4099a992 (finder: local module finder @284bd160 (roots: /home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules,/home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules/system/layers/base))]
> at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.synchronizeData(HotRodTargetMigrator.java:63)
> at org.infinispan.upgrade.RollingUpgradeManager.synchronizeData(RollingUpgradeManager.java:59)
> ... 14 more
> Caused by: java.lang.ClassNotFoundException: org.infinispan.util.ByteArrayKey from [Module "org.infinispan:main" from local module loader @4099a992 (finder: local module finder @284bd160 (roots: /home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules,/home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:947)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1259)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184)
> at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:777)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:656)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:140)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:118)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.synchronizeData(HotRodTargetMigrator.java:61)
> ... 15 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month