[JBoss JIRA] (ISPN-2911) Introduce configuration builders for Lucene cache store
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-2911:
-------------------------------------
Summary: Introduce configuration builders for Lucene cache store
Key: ISPN-2911
URL: https://issues.jboss.org/browse/ISPN-2911
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores, Lucene Directory
Affects Versions: 5.2.4.Final
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 5.3.0.Final
The Lucene Cache Stores should be configurable using the programmatic builders and the declarative parser
--
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, 10 months
[JBoss JIRA] (ISPN-2910) Divide by zero exception on shutdown
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-2910:
----------------------------------
Summary: Divide by zero exception on shutdown
Key: ISPN-2910
URL: https://issues.jboss.org/browse/ISPN-2910
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.2.1.Final
Reporter: Paul Ferraro
Assignee: Mircea Markus
19:40:50,671 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,shared=udp) ISPN000094: Received new cluster view: [perf20/web|13] [perf20/web, perf21/web]
19:40:50,754 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (notification-thread-0) ISPN000196: Failed to recover cluster state after the current node became the coordinator: java.lang.ArithmeticException: / by zero
at org.infinispan.distribution.ch.DefaultConsistentHashFactory.addPrimaryOwners(DefaultConsistentHashFactory.java:130)
at org.infinispan.distribution.ch.DefaultConsistentHashFactory.rebalanceBuilder(DefaultConsistentHashFactory.java:124)
at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:86)
at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:45)
at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheStatusAfterMerge(ClusterTopologyManagerImpl.java:306)
at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:236)
at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:597)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_38]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_38]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38]
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_38]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_38]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38]
--
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, 10 months
[JBoss JIRA] (ISPN-2910) Divide by zero exception on shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2910?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-2910:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=920079
> Divide by zero exception on shutdown
> ------------------------------------
>
> Key: ISPN-2910
> URL: https://issues.jboss.org/browse/ISPN-2910
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
>
> 19:40:50,671 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,shared=udp) ISPN000094: Received new cluster view: [perf20/web|13] [perf20/web, perf21/web]
> 19:40:50,754 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (notification-thread-0) ISPN000196: Failed to recover cluster state after the current node became the coordinator: java.lang.ArithmeticException: / by zero
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.addPrimaryOwners(DefaultConsistentHashFactory.java:130)
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.rebalanceBuilder(DefaultConsistentHashFactory.java:124)
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:86)
> at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:45)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheStatusAfterMerge(ClusterTopologyManagerImpl.java:306)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:236)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:597)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_38]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_38]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_38]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_38]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38]
--
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, 10 months
[JBoss JIRA] (ISPN-604) Re-design CacheStore transactions
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-604?page=com.atlassian.jira.plugin.s... ]
Sanne Grinovero updated ISPN-604:
---------------------------------
Description:
Current(4.1.x) transaction implementation in CacheStores is brocken in several ways:
1st problem.
{code}AbstractCacheStore.prepare:
public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException {
if (isOnePhase) {
applyModifications(mods);
} else {
transactions.put(tx, mods);
}
}
{code}
If this is 1PC we apply the modifications in the prepare phase - we should do it in the commit phase (as JTA does it).
2nd problem.
This currently exhibits during commit/rollback with JdbcXyzCacheStore, but it is rather a more general cache store issue.
When using a TransactionManager, during TM.commit AbstractCacheStore.commit is being called internally which tries to apply all the modifications that happened during that transaction.
Within the scope of AbstractCacheStore.commit, JdbcStore obtains a connection from a DataSource and tries to write the modifications on that connection.
Now if the DataSource is managed (e.g. by an A.S.) on the DS.getConnection call the A.S. would try to enlist the connection with the ongoing transaction by calling Transaction.enlistResource(XAResource xaRes) [1]
This method fails with an IllegalStateException, because the transaction's status is preparing (see javax.transaction.Transaction.enlistResource).
Suggested fix:
- the modifications should be registered to the transaction as they happen(vs. during prepare/commit as it happens now)
- this requires API changes in CacheStore, e.g.
void store(InternalCacheEntry entry)
should become
void store(InternalCacheEntry entry, GlobalTransaction gtx)
(gtx would be null if this is not a transactional call).
[1] This behavior is specified by the JDBC 2.0 Standard Extension API, chapter 7 - distributed transaction
was:
Current(4.1.x) transaction implementation in CacheStores is brocken in several ways:
1st problem.
- AbstractCacheStore.prepare:
public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException {
if (isOnePhase) {
applyModifications(mods);
} else {
transactions.put(tx, mods);
}
}
If this is 1PC we apply the modifications in the prepare phase - we should do it in the commit phase (as JTA does it).
2nd problem.
This currently exhibits during commit/rollback with JdbcXyzCacheStore, but it is rather a more general cache store issue.
When using a TransactionManager, during TM.commit AbstractCacheStore.commit is being called internally which tries to apply all the modifications that happened during that transaction.
Within the scope of AbstractCacheStore.commit, JdbcStore obtains a connection from a DataSource and tries to write the modifications on that connection.
Now if the DataSource is managed (e.g. by an A.S.) on the DS.getConnection call the A.S. would try to enlist the connection with the ongoing transaction by calling Transaction.enlistResource(XAResource xaRes) [1]
This method fails with an IllegalStateException, because the transaction's status is preparing (see javax.transaction.Transaction.enlistResource).
Suggested fix:
- the modifications should be registered to the transaction as they happen(vs. during prepare/commit as it happens now)
- this requires API changes in CacheStore, e.g.
void store(InternalCacheEntry entry)
should become
void store(InternalCacheEntry entry, GlobalTransaction gtx)
(gtx would be null if this is not a transactional call).
[1] This behavior is specified by the JDBC 2.0 Standard Extension API, chapter 7 - distributed transaction
> Re-design CacheStore transactions
> ----------------------------------
>
> Key: ISPN-604
> URL: https://issues.jboss.org/browse/ISPN-604
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores, Transactions
> Affects Versions: 4.0.0.Final, 4.1.0.CR2
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
> Labels: as7-ignored, modshape
> Fix For: 5.3.0.Final
>
>
> Current(4.1.x) transaction implementation in CacheStores is brocken in several ways:
> 1st problem.
> {code}AbstractCacheStore.prepare:
> public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException {
> if (isOnePhase) {
> applyModifications(mods);
> } else {
> transactions.put(tx, mods);
> }
> }
> {code}
> If this is 1PC we apply the modifications in the prepare phase - we should do it in the commit phase (as JTA does it).
> 2nd problem.
> This currently exhibits during commit/rollback with JdbcXyzCacheStore, but it is rather a more general cache store issue.
> When using a TransactionManager, during TM.commit AbstractCacheStore.commit is being called internally which tries to apply all the modifications that happened during that transaction.
> Within the scope of AbstractCacheStore.commit, JdbcStore obtains a connection from a DataSource and tries to write the modifications on that connection.
> Now if the DataSource is managed (e.g. by an A.S.) on the DS.getConnection call the A.S. would try to enlist the connection with the ongoing transaction by calling Transaction.enlistResource(XAResource xaRes) [1]
> This method fails with an IllegalStateException, because the transaction's status is preparing (see javax.transaction.Transaction.enlistResource).
> Suggested fix:
> - the modifications should be registered to the transaction as they happen(vs. during prepare/commit as it happens now)
> - this requires API changes in CacheStore, e.g.
> void store(InternalCacheEntry entry)
> should become
> void store(InternalCacheEntry entry, GlobalTransaction gtx)
> (gtx would be null if this is not a transactional call).
> [1] This behavior is specified by the JDBC 2.0 Standard Extension API, chapter 7 - distributed transaction
--
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, 10 months
[JBoss JIRA] (ISPN-2907) File size > Integer.MAX_VALUE crashes Lucene CacheLoader
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2907?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-2907:
----------------------------------
Fix Version/s: 5.3.0.Alpha1
> File size > Integer.MAX_VALUE crashes Lucene CacheLoader
> --------------------------------------------------------
>
> Key: ISPN-2907
> URL: https://issues.jboss.org/browse/ISPN-2907
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 4.2.1.FINAL
> Environment: Linux 3.7.10, Java 1.7.0_15
> Reporter: James Aley
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.Alpha1
>
>
> The Lucene CacheLoader can crash because of java.lang.NegativeArraySizeException caused by integer truncation when file sizes are over Integer.MAX_VALUE. We probably shouldn't cast the file length to int, to avoid this?
> Caused by: org.infinispan.loaders.CacheLoaderException: ISPN015008: IOException happened in the CacheLoader
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.load(DirectoryLoaderAdaptor.java:205)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:75)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:170)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeededAndUpdateStats(CacheLoaderInterceptor.java:231)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:112)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:126)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitGetKeyValueCommand(NonTransactionalLockingInterceptor.java:60)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:216)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:200)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> ... 51 more
> Caused by: java.lang.NegativeArraySizeException
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadIntern(DirectoryLoaderAdaptor.java:268)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.access$300(DirectoryLoaderAdaptor.java:49)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor$LoadVisitor.visit(DirectoryLoaderAdaptor.java:313)
> at org.infinispan.lucene.ChunkCacheKey.accept(ChunkCacheKey.java:92)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.load(DirectoryLoaderAdaptor.java:203)
> ... 81 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, 10 months
[JBoss JIRA] (ISPN-2907) File size > Integer.MAX_VALUE crashes Lucene CacheLoader
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2907?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-2907:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1713
> File size > Integer.MAX_VALUE crashes Lucene CacheLoader
> --------------------------------------------------------
>
> Key: ISPN-2907
> URL: https://issues.jboss.org/browse/ISPN-2907
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 4.2.1.FINAL
> Environment: Linux 3.7.10, Java 1.7.0_15
> Reporter: James Aley
> Assignee: Sanne Grinovero
>
> The Lucene CacheLoader can crash because of java.lang.NegativeArraySizeException caused by integer truncation when file sizes are over Integer.MAX_VALUE. We probably shouldn't cast the file length to int, to avoid this?
> Caused by: org.infinispan.loaders.CacheLoaderException: ISPN015008: IOException happened in the CacheLoader
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.load(DirectoryLoaderAdaptor.java:205)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:75)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:170)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeededAndUpdateStats(CacheLoaderInterceptor.java:231)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:112)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:126)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitGetKeyValueCommand(NonTransactionalLockingInterceptor.java:60)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:216)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:200)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:104)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:58)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> ... 51 more
> Caused by: java.lang.NegativeArraySizeException
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadIntern(DirectoryLoaderAdaptor.java:268)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.access$300(DirectoryLoaderAdaptor.java:49)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor$LoadVisitor.visit(DirectoryLoaderAdaptor.java:313)
> at org.infinispan.lucene.ChunkCacheKey.accept(ChunkCacheKey.java:92)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.load(DirectoryLoaderAdaptor.java:203)
> ... 81 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, 10 months