[JBoss JIRA] (ISPN-10721) jcache/tck-runner module should not unpack cache-tests
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10721?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10721:
-----------------------------------
Sprint: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> jcache/tck-runner module should not unpack cache-tests
> ------------------------------------------------------
>
> Key: ISPN-10721
> URL: https://issues.jboss.org/browse/ISPN-10721
> Project: Infinispan
> Issue Type: Bug
> Components: JCache, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: dan.berindei
> Assignee: dan.berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Final
>
>
> The {{jcache/tck-runner}} module is unpacking the {{cache-tests}} dependency (the TCK) in the target directory so that the Surefire Maven plugin can find and run the tests.
> This started breaking since the upgrade to Weld 2.3.4.Final (ISPN-10383), because Weld now finds the TCK beans in two different locations:
> {noformat}
> [2019-10-01T07:12:01.511Z] [OK: 214, KO: 1, SKIP: 0] Test failed: InterceptionUsingCacheConfigTest.test_AT_CacheResult
> [2019-10-01T07:12:01.511Z] org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318: Cannot resolve an ambiguous dependency between:
> [2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default],
> [2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default]
> [2019-10-01T07:12:01.511Z] at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1235)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotations.cdi.test.CdiBeanProvider.getBeanByType(CdiBeanProvider.java:47)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractInterceptionTest.getBeanByType(AbstractInterceptionTest.java:66)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.InterceptionUsingCacheConfigTest.getBlogManager(InterceptionUsingCacheConfigTest.java:23)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractBlogManagerInterceptionTest.before(AbstractBlogManagerInterceptionTest.java:26)
> {noformat}
> Fortunately we don't have to unpack the tests in our working directory, we can tell Surefire to run the tests from the jar instead:
> {code:xml}
> <dependenciesToScan>
> <dependency>javax.cache:cache-tests</dependency>
> </dependenciesToScan>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10743) Serializer should only serialize user defined AdvancedExternalizers
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10743?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10743:
-----------------------------------
Sprint: DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: DataGrid Sprint #35, DataGrid Sprint #36)
> Serializer should only serialize user defined AdvancedExternalizers
> -------------------------------------------------------------------
>
> Key: ISPN-10743
> URL: https://issues.jboss.org/browse/ISPN-10743
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 10.0.0.CR3
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> ISPN-10727 Is caused because the Serialization configuration is deemed to have been modified by a user in the test setup. However, the classes being serialized are the internal Externalizers that are defined in various modules ModuleLifecycle implementations and are of no significance to the user, as they will always be applied regardless of the xml configuration. Therefore, we should hide all internal Externalizer classes from the user.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10749) Invalidation mode needs a proper key partitioner
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10749?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10749:
-----------------------------------
Sprint: DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: DataGrid Sprint #35, DataGrid Sprint #36)
> Invalidation mode needs a proper key partitioner
> ------------------------------------------------
>
> Key: ISPN-10749
> URL: https://issues.jboss.org/browse/ISPN-10749
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.16.Final, 10.0.0.CR3
> Reporter: dan.berindei
> Assignee: dan.berindei
> Priority: Major
> Fix For: 10.1.0.Final
>
>
> Caches in invalidation mode used to do everything on the local node and only broadcast an invalidation command to all the members. ISPN-10029 changed this, and now transactional invalidation caches acquire locks for affected keys on the primary owners.
> Unfortunately {{KeyPartitionerFactory}} constructs a {{SingleSegmentKeyPartitioner}} in invalidation mode, so there is only one primary owner for all the keys.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10578) ScatteredCache RemoteMetadata should be handled by the PersistenceMarshaller
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10578?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10578:
-----------------------------------
Sprint: DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> ScatteredCache RemoteMetadata should be handled by the PersistenceMarshaller
> ----------------------------------------------------------------------------
>
> Key: ISPN-10578
> URL: https://issues.jboss.org/browse/ISPN-10578
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.CR1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.CR2
>
>
> When running {{SharedStoreTest#testUnnecessaryWrites}} a {{NotSerializableException}} is being thrown because `RemoteMetadata` is not marshallable by the persistence marshaller. This does not cause any tests to fail, however it appears in the log files for every test run.
> {code:java}
> 00:46:16,116 WARN (remote-thread-Test-NodeC-p19-t2) [PersistenceMarshallerImpl] Cannot marshall org.infinispan.container.entries.RemoteMetadata
> org.infinispan.commons.marshall.MarshallingException: java.io.NotSerializableException: org.infinispan.container.entries.RemoteMetadata
> at org.infinispan.marshall.persistence.impl.PersistenceMarshallerImpl.marshallUserObject(PersistenceMarshallerImpl.java:220) ~[classes/:?]
> at org.infinispan.marshall.persistence.impl.PersistenceMarshallerImpl.wrapUserObject(PersistenceMarshallerImpl.java:251) ~[classes/:?]
> at org.infinispan.marshall.persistence.impl.PersistenceMarshallerImpl.objectToBuffer(PersistenceMarshallerImpl.java:159) ~[classes/:?]
> at org.infinispan.marshall.persistence.impl.PersistenceMarshallerImpl.objectToBuffer(PersistenceMarshallerImpl.java:136) ~[classes/:?]
> at org.infinispan.marshall.persistence.impl.MarshallableEntryImpl.marshall(MarshallableEntryImpl.java:209) ~[classes/:?]
> at org.infinispan.marshall.persistence.impl.MarshallableEntryImpl.<init>(MarshallableEntryImpl.java:38) ~[classes/:?]
> at org.infinispan.marshall.persistence.impl.MarshalledEntryFactoryImpl.create(MarshalledEntryFactoryImpl.java:64) ~[classes/:?]
> at org.infinispan.interceptors.impl.CacheWriterInterceptor.marshalledEntry(CacheWriterInterceptor.java:525) ~[classes/:?]
> at org.infinispan.interceptors.impl.CacheWriterInterceptor.storeEntry(CacheWriterInterceptor.java:505) ~[classes/:?]
> at org.infinispan.interceptors.impl.CacheWriterInterceptor.storeEntry(CacheWriterInterceptor.java:498) ~[classes/:?]
> at org.infinispan.interceptors.impl.ScatteredCacheWriterInterceptor.storeAndUpdateStats(ScatteredCacheWriterInterceptor.java:166) ~[classes/:?]
> at org.infinispan.interceptors.impl.ScatteredCacheWriterInterceptor.lambda$handleDataWriteReturn$1(ScatteredCacheWriterInterceptor.java:154) ~[classes/:?]
> at org.infinispan.persistence.manager.OrderedUpdatesManagerImpl.checkLockAndStore(OrderedUpdatesManagerImpl.java:84) ~[classes/:?]
> at org.infinispan.interceptors.impl.ScatteredCacheWriterInterceptor.handleDataWriteReturn(ScatteredCacheWriterInterceptor.java:152) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:86) ~[classes/:?]
> at org.infinispan.interceptors.impl.ScatteredCacheWriterInterceptor.visitPutKeyValueCommand(ScatteredCacheWriterInterceptor.java:171) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:61) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.asyncInvokeNext(BaseAsyncInterceptor.java:232) ~[classes/:?]
> at org.infinispan.interceptors.impl.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:224) ~[classes/:?]
> at org.infinispan.interceptors.impl.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:144) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:61) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:188) ~[classes/:?]
> at org.infinispan.interceptors.impl.BiasedEntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(BiasedEntryWrappingInterceptor.java:38) ~[classes/:?]
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:318) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:61) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59) ~[classes/:?]
> at org.infinispan.interceptors.impl.PrefetchInterceptor.handleWriteCommand(PrefetchInterceptor.java:370) ~[classes/:?]
> at org.infinispan.interceptors.impl.PrefetchInterceptor.visitPutKeyValueCommand(PrefetchInterceptor.java:387) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:61) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:188) ~[classes/:?]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:309) ~[classes/:?]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:252) ~[classes/:?]
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:96) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:61) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59) ~[classes/:?]
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:212) ~[classes/:?]
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:177) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:61) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59) ~[classes/:?]
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:53) ~[classes/:?]
> at org.infinispan.interceptors.DDAsyncInterceptor.visitPutKeyValueCommand(DDAsyncInterceptor.java:59) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:61) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:128) ~[classes/:?]
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:89) ~[classes/:?]
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:61) ~[classes/:?]
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:53) ~[classes/:?]
> at org.infinispan.interceptors.DDAsyncInterceptor.visitPutKeyValueCommand(DDAsyncInterceptor.java:59) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:61) ~[classes/:?]
> at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:49) ~[classes/:?]
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:244) ~[classes/:?]
> at org.infinispan.statetransfer.StateConsumerImpl.doApplyState(StateConsumerImpl.java:666) ~[classes/:?]
> at org.infinispan.statetransfer.StateConsumerImpl.applyChunk(StateConsumerImpl.java:632) ~[classes/:?]
> at org.infinispan.statetransfer.StateConsumerImpl.lambda$applyState$1(StateConsumerImpl.java:588) ~[classes/:?]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java) [?:?]
> at org.infinispan.commons.util.concurrent.CallerRunsRejectOnShutdownPolicy.rejectedExecution(CallerRunsRejectOnShutdownPolicy.java:19) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:825) [?:?]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1355) [?:?]
> at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) [?:?]
> at org.infinispan.executors.LazyInitializingExecutorService.submit(LazyInitializingExecutorService.java:108) [classes/:?]
> at org.infinispan.statetransfer.StateConsumerImpl.applyState(StateConsumerImpl.java:586) [classes/:?]
> at org.infinispan.statetransfer.StateResponseCommand.invokeAsync(StateResponseCommand.java:92) [classes/:?]
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:118) [classes/:?]
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:100) [classes/:?]
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:72) [classes/:?]
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:41) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.io.NotSerializableException: org.infinispan.container.entries.RemoteMetadata
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1185) ~[?:?]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:349) ~[?:?]
> at org.infinispan.commons.marshall.JavaSerializationMarshaller.objectToBuffer(JavaSerializationMarshaller.java:39) ~[classes/:?]
> at org.infinispan.commons.marshall.AbstractMarshaller.objectToByteBuffer(AbstractMarshaller.java:70) ~[classes/:?]
> at org.infinispan.commons.marshall.AbstractMarshaller.objectToByteBuffer(AbstractMarshaller.java:60) ~[classes/:?]
> at org.infinispan.marshall.persistence.impl.PersistenceMarshallerImpl.marshallUserObject(PersistenceMarshallerImpl.java:215) ~[classes/:?]
> ... 70 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10611) Jenkins ignores server/runtime test failures
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10611?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10611:
-----------------------------------
Sprint: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> Jenkins ignores server/runtime test failures
> --------------------------------------------
>
> Key: ISPN-10611
> URL: https://issues.jboss.org/browse/ISPN-10611
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: dan.berindei
> Assignee: dan.berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> {{server/runtime}} test suite uses JUnit, so it should not disable the native xml report. Need
> {noformat}
> <disableXmlReport>false</disableXmlReport>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10557) extended-statistics org.infinispan.stats package overlaps with core
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10557?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10557:
-----------------------------------
Sprint: DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> extended-statistics org.infinispan.stats package overlaps with core
> -------------------------------------------------------------------
>
> Key: ISPN-10557
> URL: https://issues.jboss.org/browse/ISPN-10557
> Project: Infinispan
> Issue Type: Bug
> Components: Build, Core
> Affects Versions: 10.0.0.CR1
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.CR2
>
>
> The org.infinispan.stats package is used both within infinispan-core and infinispan-extended-statistics. This shold be fixed in the extended statistics module
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10609) Extend Marshaller interface to expose configured ClassWhiteList to implementation
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10609?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10609:
-----------------------------------
Sprint: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> Extend Marshaller interface to expose configured ClassWhiteList to implementation
> ---------------------------------------------------------------------------------
>
> Key: ISPN-10609
> URL: https://issues.jboss.org/browse/ISPN-10609
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 10.0.0.CR2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> ClassWhiteList is a generic white list that can be configured via our XML, it doesn't have anything specifc to Serialization. We should allow a user's marshaller implementation, set via SerializationConfiguration#marshaller, to utilise the configured values to limit what can/can't be marshalled.
> For our internal code this is nice because it will prevent us from requiring hacky code like the following in the PersistenceMarshallerImpl if the user wants to utilise our provided JavaSerializationMarshaller:
> {code:java}
> if (userMarshaller instanceof JavaSerializationMarshaller) {
> ((JavaSerialzationMarshaller) userMarshaller).setWhiteList(whiteListImpl);
> } else if (userMarshaller instanceof ...) {
> ...
> }
> {code}
> Proposed change to the Marshaller interface:
> {code:java}
> default void initialize(ClassWhiteList whiteList) {
> // no-op
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10574) Off Heap iteration performance improvements
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10574?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10574:
-----------------------------------
Sprint: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> Off Heap iteration performance improvements
> -------------------------------------------
>
> Key: ISPN-10574
> URL: https://issues.jboss.org/browse/ISPN-10574
> Project: Infinispan
> Issue Type: Enhancement
> Components: Off Heap
> Affects Versions: 10.0.0.CR1
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.CR3, 10.0.0.Final
>
>
> When testing out some things it was found that an off heap cache with a single entry compared to an object one takes significantly longer for state transfer. Off Heap can be improved to make iteration faster and thus improve things like state transfer.
> # Off Heap entries are stored using modulus for locks. This causes iteration to not access entries sequentially as well as having to acquire the same lock many times over.
> # Off Heap should optimize code paths that can be short circuited (ie. don't create stream if size is 0)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months