[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3918:
------------------------------------
The situation is even worse when the topology changes: a {{get}} after a failed {{putIfAbsent}} can return not only {{null}}, but also a completely different value.
Say {{owners(k) = AB}}, and there is a topology change but the owners of {{k}} stay the same. In the following scenario, thread _B-app3_ first sees {{putIfAbsent(k, v3) = v2}}, and then {{get(k) = v1}} (_B-appX_ means application thread X on B, and _A-remoteX_ means remote thread X on A):
# _B-app1_: start putIfAbsent(k, v1)
# _B-app1_: send putIfAbsent(k, v1) to A (primary)
# _A-remote1_: receive putIfAbsent(k, v1)
# _A-remote1_: send backup request for putIfAbsent(k, v1) to B
# _B-remote1_: receive backup request for putIfAbsent(k, v1)
# _B-remote1_: write k=v1
# _B-remote1_: send backup ack for putIfAbsent(k, v1)
# _A-remote1_: check topology, send OutdatedTopologyException back to B
# _A-app2_: start putIfAbsent(k, v2)
# _A-app2_: send backup request for putIfAbsent(k, v2) to B
# _A-app2_: write k=v2
# _B-app3_: start putIfAbsent(k, v3)
# _B-app3_: send putIfAbsent(k, v3) to A (primary)
# _A-remote3_: receive putIfAbsent(k, v3)
# _A-remote3_: read v2 from data container, fail the command
# _B-remote3_: receive v2 for putIfAbsent(k, v3)
# *_B-app3_: return v2 for putIfAbsent(k, v3) (put was unsuccessful)*
# _B-app3_: start get(k)
# _B-app3_: read v1 from local container
# *_B-app3_: return v1 for get(k)*
# _B-remote2_: receive putIfAbsent(k, v2) backup command
# _B-remote2_: write k=v2
# _B-remote2_: send backup ack for putIfAbsent(k, v2)
# _A-remote2_: receive backup ack for putIfAbsent(k, v2)
# *_A-app2_: return null for putIfAbsent(k, v2) (put was successful)*
# _B-remote1_: receive OutdatedTopologyException for putIfAbsent(k, v1)
# _B-remote1_: retry, send putIfAbsent(k, v1) to A (primary)
# _A-remote1_: receive putIfAbsent(k, v1)
# _A-remote1_: read v2 from data container, fail the command
# _B-remote1_: receive v2 for putIfAbsent(k, v1)
# *_B-app1_: return v2 for putIfAbsent(k, v1) (put was unsuccessful)*
> Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3918
> URL: https://issues.jboss.org/browse/ISPN-3918
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Labels: consistency
> Fix For: 9.2.0.Final
>
> Attachments: ntpiadjst.log.gz
>
>
> In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls.
> Say \[B, A, C] are the owners of k (C just joined)
> 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B
> 2. B forwards the command to A and C
> 3. C writes {{k=v1}}
> 4. C becomes the primary owner of k (owners are now \[C, A])
> 5. A/B see the new topology before committing and throw an outdatedTopologyException
> 6. A retries the command, sends it to C
> 7. C forwards the command to A, which writes {{k=v1}}
> 8. C doesn't have to update the entry, returns null
> If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-8189) SizeCommand unnecessarily unmarshalls keys to count
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-8189:
-------------------------------------
Summary: SizeCommand unnecessarily unmarshalls keys to count
Key: ISPN-8189
URL: https://issues.jboss.org/browse/ISPN-8189
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.1.0.Final
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 9.1.1.Final
The SizeCommand uses cache.keySet().stream().count() to count keys, but if the cache is using binary storage, this unmarshalls each key.
Using the identityencoder allows us to make this operation much cheaper.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-8188) StateTransferLargeObjectTest random failures
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-8188:
---------------------------------------
Summary: StateTransferLargeObjectTest random failures
Key: ISPN-8188
URL: https://issues.jboss.org/browse/ISPN-8188
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 9.1.0.Final
Reporter: Gustavo Fernandes
{noformat}
[ERROR] testForFailure(org.infinispan.statetransfer.StateTransferLargeObjectTest) Time elapsed: 0.314 s <<< FAILURE!
org.infinispan.commons.CacheException: java.lang.IllegalStateException
at org.infinispan.interceptors.impl.InvocationContextInterceptor.rethrowException(InvocationContextInterceptor.java:144)
at org.infinispan.interceptors.impl.InvocationContextInterceptor.access$000(InvocationContextInterceptor.java:44)
at org.infinispan.interceptors.impl.InvocationContextInterceptor$1.apply(InvocationContextInterceptor.java:61)
at org.infinispan.interceptors.InvocationExceptionFunction.apply(InvocationExceptionFunction.java:21)
at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:67)
at org.infinispan.interceptors.InvocationStage.andExceptionally(InvocationStage.java:34)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:132)
at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:97)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:60)
at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
at org.infinispan.interceptors.DDAsyncInterceptor.visitGetKeyValueCommand(DDAsyncInterceptor.java:106)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248)
at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:501)
at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:494)
at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:348)
at org.infinispan.cache.impl.EncoderCache.get(EncoderCache.java:631)
at org.infinispan.statetransfer.StateTransferLargeObjectTest.testForFailure(StateTransferLargeObjectTest.java:76)
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.access$000(SuiteRunner.java:38)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.remoteGet(BaseDistributionInterceptor.java:163)
at org.infinispan.interceptors.distribution.TxDistributionInterceptor.remoteGet(TxDistributionInterceptor.java:533)
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleMissingEntryOnLocalRead(BaseDistributionInterceptor.java:858)
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.onEntryMiss(BaseDistributionInterceptor.java:853)
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.visitGetCommand(BaseDistributionInterceptor.java:848)
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.visitGetKeyValueCommand(BaseDistributionInterceptor.java:865)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:102)
at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitDataReadCommand(EntryWrappingInterceptor.java:217)
at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:205)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
at org.infinispan.interceptors.DDAsyncInterceptor.visitGetKeyValueCommand(DDAsyncInterceptor.java:106)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitDataReadCommand(OptimisticLockingInterceptor.java:52)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:110)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
at org.infinispan.interceptors.impl.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:374)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:41)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:189)
at org.infinispan.interceptors.impl.BaseStateTransferInterceptor.updateAndInvokeNextRead(BaseStateTransferInterceptor.java:196)
at org.infinispan.interceptors.impl.BaseStateTransferInterceptor.handleReadCommand(BaseStateTransferInterceptor.java:191)
at org.infinispan.interceptors.impl.BaseStateTransferInterceptor.visitGetKeyValueCommand(BaseStateTransferInterceptor.java:174)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:94)
at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:83)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:127)
... 32 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-8187) Random failures in Memcached testsuite due to port conflicts
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-8187:
---------------------------------------
Summary: Random failures in Memcached testsuite due to port conflicts
Key: ISPN-8187
URL: https://issues.jboss.org/browse/ISPN-8187
Project: Infinispan
Issue Type: Bug
Affects Versions: 9.1.0.Final
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
{noformat}
[ERROR] testStoreAsBinaryOverride(org.infinispan.server.memcached.MemcachedFunctionalTest) Time elapsed: 0.028 s <<< FAILURE!
io.netty.channel.unix.Errors$NativeIoException: bind(..) failed: Address already in use
at io.netty.channel.unix.Errors.newIOException(Errors.java:117)
at io.netty.channel.unix.Socket.bind(Socket.java:234)
at io.netty.channel.epoll.EpollServerSocketChannel.doBind(EpollServerSocketChannel.java:91)
at io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:554)
at io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1258)
at io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:501)
at io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:486)
at io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:980)
at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:250)
at io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:365)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:403)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:304)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-8175) LocalCacheStateTransferTest random failures
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8175?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8175:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> LocalCacheStateTransferTest random failures
> -------------------------------------------
>
> Key: ISPN-8175
> URL: https://issues.jboss.org/browse/ISPN-8175
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.1.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
>
> {noformat}
> [ERROR] testStateTransferWithClusterIdle(org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest) Time elapsed: 0.698 s <<< FAILURE!
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49)
> at org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest.assertNoStateTransferInReceivingSite(LocalCacheStateTransferTest.java:147)
> at org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest.testStateTransferWithClusterIdle(LocalCacheStateTransferTest.java:96)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-8170) Disable maven download progress indication in CI
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8170?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8170:
----------------------------------
Fix Version/s: 9.0.4.Final
> Disable maven download progress indication in CI
> ------------------------------------------------
>
> Key: ISPN-8170
> URL: https://issues.jboss.org/browse/ISPN-8170
> Project: Infinispan
> Issue Type: Task
> Components: Build process
> Affects Versions: 8.2.8.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.4.Final, 8.2.9.Final
>
>
> CI build logs are too big, and sometimes they're full of stuff like this:
> {noformat}
> 831/831 B ^M ^MUploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/inf...
> /infinispan-as-client-modules/8.2.8-SNAPSHOT/maven-metadata.xml (831 B at 1.6 KB/sec)
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/inf...
> es/8.2.8-SNAPSHOT/infinispan-as-client-modules-8.2.8-20170703.105949-1.zip
> 2/2647 KB ^M4/2647 KB ^M6/2647 KB ^M8/2647 KB ^M10/2647 KB ^M12/2647 KB ^M14/2647 KB ^M16/2647 KB ^M18
> /2647 KB ^M20/2647 KB ^M22/2647 KB ^M24/2647 KB ^M26/2647 KB ^M28/2647 KB ^M30/2647 KB ^M32/2647 KB ^M
> 34/2647 KB ^M36/2647 KB ^M38/2647 KB ^M40/2647 KB ^M42/2647 KB ^M44/2647 KB ^M46/2647 KB ^M48/2647 KB
> ^M50/2647 KB ^M52/2647 KB ^M54/2647 KB ^M56/2647 KB ^M58/2647 KB ^M60/2647 KB ^M62/2647 KB ^M64/2647 KB
> ^M66/2647 KB ^M68/2647 KB ^M70/2647 KB ^M72/2647 KB ^M74/2647 KB ^M76/2647 KB ^M78/2647 KB ^M80/2647 K
> B ^M82/2647 KB ^M84/2647 KB ^M86/2647 KB ^M88/2647 KB ^M90/2647 KB ^M92/2647 KB ^M94/2647 KB ^M96/2647
> KB ^M98/2647 KB ^M100/2647 KB ^M102/2647 KB ^M104/2647 KB ^M106/2647 KB ^M108/2647 KB ^M110/2647 KB
> ^M112/2647 KB ^M114/2647 KB ^M116/2647 KB ^M118/2647 KB ^M120/2647 KB ^M122/2647 KB ^M124/2647 KB ^M126/
> 2647 KB ^M128/2647 KB ^M130/2647 KB ^M132/2647 KB ^M134/2647 KB ^M136/2647 KB ^M138/2647 KB ^M140/2647 K
> B ^M142/2647 KB ^M144/2647 KB ^M146/2647 KB ^M148/2647 KB ^M150/2647 KB ^M152/2647 KB ^M154/2647 KB ^M
> 156/2647 KB ^M158/2647 KB ^M160/2647 KB ^M162/2647 KB ^M164/2647 KB ^M166/2647 KB ^M168/2647 KB ^M170/26
> {noformat}
> We should use batch mode in order to disable the download/upload progress logs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-8170) Disable maven download progress indication in CI
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8170?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8170:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Disable maven download progress indication in CI
> ------------------------------------------------
>
> Key: ISPN-8170
> URL: https://issues.jboss.org/browse/ISPN-8170
> Project: Infinispan
> Issue Type: Task
> Components: Build process
> Affects Versions: 8.2.8.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.4.Final, 8.2.9.Final
>
>
> CI build logs are too big, and sometimes they're full of stuff like this:
> {noformat}
> 831/831 B ^M ^MUploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/inf...
> /infinispan-as-client-modules/8.2.8-SNAPSHOT/maven-metadata.xml (831 B at 1.6 KB/sec)
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/inf...
> es/8.2.8-SNAPSHOT/infinispan-as-client-modules-8.2.8-20170703.105949-1.zip
> 2/2647 KB ^M4/2647 KB ^M6/2647 KB ^M8/2647 KB ^M10/2647 KB ^M12/2647 KB ^M14/2647 KB ^M16/2647 KB ^M18
> /2647 KB ^M20/2647 KB ^M22/2647 KB ^M24/2647 KB ^M26/2647 KB ^M28/2647 KB ^M30/2647 KB ^M32/2647 KB ^M
> 34/2647 KB ^M36/2647 KB ^M38/2647 KB ^M40/2647 KB ^M42/2647 KB ^M44/2647 KB ^M46/2647 KB ^M48/2647 KB
> ^M50/2647 KB ^M52/2647 KB ^M54/2647 KB ^M56/2647 KB ^M58/2647 KB ^M60/2647 KB ^M62/2647 KB ^M64/2647 KB
> ^M66/2647 KB ^M68/2647 KB ^M70/2647 KB ^M72/2647 KB ^M74/2647 KB ^M76/2647 KB ^M78/2647 KB ^M80/2647 K
> B ^M82/2647 KB ^M84/2647 KB ^M86/2647 KB ^M88/2647 KB ^M90/2647 KB ^M92/2647 KB ^M94/2647 KB ^M96/2647
> KB ^M98/2647 KB ^M100/2647 KB ^M102/2647 KB ^M104/2647 KB ^M106/2647 KB ^M108/2647 KB ^M110/2647 KB
> ^M112/2647 KB ^M114/2647 KB ^M116/2647 KB ^M118/2647 KB ^M120/2647 KB ^M122/2647 KB ^M124/2647 KB ^M126/
> 2647 KB ^M128/2647 KB ^M130/2647 KB ^M132/2647 KB ^M134/2647 KB ^M136/2647 KB ^M138/2647 KB ^M140/2647 K
> B ^M142/2647 KB ^M144/2647 KB ^M146/2647 KB ^M148/2647 KB ^M150/2647 KB ^M152/2647 KB ^M154/2647 KB ^M
> 156/2647 KB ^M158/2647 KB ^M160/2647 KB ^M162/2647 KB ^M164/2647 KB ^M166/2647 KB ^M168/2647 KB ^M170/26
> {noformat}
> We should use batch mode in order to disable the download/upload progress logs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months