January 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7406) Update to Hibernate Search 5.6.0.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7406?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7406: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update to Hibernate Search 5.6.0.Final > -------------------------------------- > > Key: ISPN-7406 > URL: https://issues.jboss.org/browse/ISPN-7406 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.CR1, 9.0.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7324) DDAsyncInterceptor indirection slows down replicated reads

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7324?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7324: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/4743, https://github.com/infinispan/infinispan/pull/4761 (was: https://github.com/infinispan/infinispan/pull/4743) > DDAsyncInterceptor indirection slows down replicated reads > ---------------------------------------------------------- > > Key: ISPN-7324 > URL: https://issues.jboss.org/browse/ISPN-7324 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 9.0.0.CR1 > > > Local reads are fast enough, but the additional interceptors and stage callbacks in (transactional) replicated mode seem to impact with the async interceptor stack a lot more than the classic one. > One thing that's different with the new interceptors is that {{invokeNext()}} doesn't call {{command.acceptVisitor(nextInterceptor)}} directly. Instead it calls {{nextInterceptor.visitCommand()}}, and the interceptor decides whether to use double-dispatch (by extending {{DDAsyncInterceptor}}) or another strategy. > In theory this allows us to use simpler interceptors, e.g. having just the methods {{visitReadCommand()}}, {{visitWriteCommand()}}, and {{visitTxCommand()}}. {{CallInterceptor}} already calls {{command.perform()}} for each command. For now, however, most interceptors extend {{DDAsyncInterceptor}}, and tx replicated reads are slower than in 9.0.0.Alpha0. > With transactions, the {{VisitableCommand.acceptVisitor(}} call site in {{DDAsyncInterceptor.visitCommand}} is megamorphic (since the initial preload uses put, prepare, and commit). Adding a special check in {{invokeNext()}} to invoke {{command.acceptVisitor(nextInterceptor)}} didn't help, but adding a special check for {{GetKeyValueCommand}} made a big difference on my machine: > |9.0.0.Alpha0 (CommandInterceptor)|4937351.255 ±(99.9%) 61665.164 ops/s| > |9.0.0.Beta1 (AsyncInterceptor)|4387466.151 ±(99.9%) 78665.887 ops/s| > |master before ISPN-6802 and ISPN-6803| 4247769.260 ±(99.9%) 133767.371 ops/s| > |master| 4710798.986 ±(99.9%) 166062.177 ops/s| > |master with GKVC special case| 5749357.895 ±(99.9%) 87338.878 ops/s| -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7324) DDAsyncInterceptor indirection slows down replicated reads

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7324?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7324: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > DDAsyncInterceptor indirection slows down replicated reads > ---------------------------------------------------------- > > Key: ISPN-7324 > URL: https://issues.jboss.org/browse/ISPN-7324 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 9.0.0.CR1 > > > Local reads are fast enough, but the additional interceptors and stage callbacks in (transactional) replicated mode seem to impact with the async interceptor stack a lot more than the classic one. > One thing that's different with the new interceptors is that {{invokeNext()}} doesn't call {{command.acceptVisitor(nextInterceptor)}} directly. Instead it calls {{nextInterceptor.visitCommand()}}, and the interceptor decides whether to use double-dispatch (by extending {{DDAsyncInterceptor}}) or another strategy. > In theory this allows us to use simpler interceptors, e.g. having just the methods {{visitReadCommand()}}, {{visitWriteCommand()}}, and {{visitTxCommand()}}. {{CallInterceptor}} already calls {{command.perform()}} for each command. For now, however, most interceptors extend {{DDAsyncInterceptor}}, and tx replicated reads are slower than in 9.0.0.Alpha0. > With transactions, the {{VisitableCommand.acceptVisitor(}} call site in {{DDAsyncInterceptor.visitCommand}} is megamorphic (since the initial preload uses put, prepare, and commit). Adding a special check in {{invokeNext()}} to invoke {{command.acceptVisitor(nextInterceptor)}} didn't help, but adding a special check for {{GetKeyValueCommand}} made a big difference on my machine: > |9.0.0.Alpha0 (CommandInterceptor)|4937351.255 ±(99.9%) 61665.164 ops/s| > |9.0.0.Beta1 (AsyncInterceptor)|4387466.151 ±(99.9%) 78665.887 ops/s| > |master before ISPN-6802 and ISPN-6803| 4247769.260 ±(99.9%) 133767.371 ops/s| > |master| 4710798.986 ±(99.9%) 166062.177 ops/s| > |master with GKVC special case| 5749357.895 ±(99.9%) 87338.878 ops/s| -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7399) Make visitCommand return an Object instead of an InvocationStage

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7399?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7399: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Make visitCommand return an Object instead of an InvocationStage > ---------------------------------------------------------------- > > Key: ISPN-7399 > URL: https://issues.jboss.org/browse/ISPN-7399 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.CR1 > > > Replicated read benchmarks show a significant amount of time spent in {{BasicInvocationStage.toInvocationStage()}}. > We can make {{visitCommand}} return an {{Object}} instead of an {{InvocationStage}}, and that return value can be cast to an {{InvocationStage}} when a callback is needed. We can't call {{thenApply()}} etc. directly on an {{Object}}, but we can combine {{invokeNext(ctx, command).thenApply(function)}} into {{invokeNextThenApply(ctx, command, function)}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7398) AbstractProtocolServerTest.testStartingWithoutTransport fails

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7398?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7398: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > AbstractProtocolServerTest.testStartingWithoutTransport fails > ------------------------------------------------------------- > > Key: ISPN-7398 > URL: https://issues.jboss.org/browse/ISPN-7398 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.CR1 > > > Caused by ISPN-7066 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7370) Administration console - configuration of cache store is broken

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7370?page=com.atlassian.jira.plugin.... ] Ryan Emerson commented on ISPN-7370: ------------------------------------ This happens if you select one store type and then select another. E.g. Custom Store -> String Keyed JDBC Store > Administration console - configuration of cache store is broken > --------------------------------------------------------------- > > Key: ISPN-7370 > URL: https://issues.jboss.org/browse/ISPN-7370 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.Beta1 > Reporter: Roman Macor > Assignee: Ryan Emerson > Fix For: 9.0.0.CR1 > > Attachments: Screenshot from 2017-01-19.png > > > Click on cache container -> cache -> configuration -> Store -> Select store type e.g. Binary keyed JDBC store > Issues: > some property names are displayed like this: {{$ctrl.resolveFieldName()}} > ... links (for Write Behind for example) are not working > Please see the attached screenshot for details. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7405) DMR operation register-proto-schemas fails with NPE if the proto file has syntax errors

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7405?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-7405: ------------------------------------ [~pruivo] the NPE was also present before, but only for non-syntax errors. E.g. {{protoBufMetadaCache.put("test.proto", "import \"missing_file.proto\";\npackage X;");}}. > DMR operation register-proto-schemas fails with NPE if the proto file has syntax errors > --------------------------------------------------------------------------------------- > > Key: ISPN-7405 > URL: https://issues.jboss.org/browse/ISPN-7405 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying, Server > Affects Versions: 9.0.0.Beta2 > Reporter: Adrian Nistor > Priority: Blocker > Fix For: 9.0.0.CR1 > > Attachments: error.log > > > Start an infinispan server and run the following CLI command: > ./bin/ispn-cli.sh -c '/subsystem=datagrid-infinispan/cache-container=local:register-proto-schemas(file-names=[myFileWithSyntaxErrors.proto], file-contents=[kaboom])' > since the file has syntax errors it should still be placed in the ___protobuf_metadata cache and a myFileWithSyntaxErrors.proto.errors key should also be created. No exception should be thrown. Currently no key is written in cache and the NPE from the attached log happens. > When registering a proper file without syntax errors this works correctly. > The problem disappears if I disable global state persistence, so the cachestore seems to play a role in this. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7405) DMR operation register-proto-schemas fails with NPE if the proto file has syntax errors

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7405?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-7405: ------------------------------------ [~anistor] the problem is that {{ProtobufMetadataInterceptor}} tries to store the {{name.proto.errors}} entry with a {{null}} metadata. This works when the cache doesn't have persistence, but it triggers a {{NullPointerException}} when {{CacheWriterInterceptor}} tries to create an {{InternalCacheEntry}} from the context entry. I see {{InternalEntryFactoryImpl}} has some checks to deal with {{null}} metadata, but it's probably not incomplete writes from {{Cache}} methods always use a non-null metadata. Ideally I think we should check that the metadata is not null in {{CommandFactoryImpl}} and {{ProtobufMetadataInterceptor}} should use the main entry's metadata. > DMR operation register-proto-schemas fails with NPE if the proto file has syntax errors > --------------------------------------------------------------------------------------- > > Key: ISPN-7405 > URL: https://issues.jboss.org/browse/ISPN-7405 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying, Server > Affects Versions: 9.0.0.Beta2 > Reporter: Adrian Nistor > Priority: Blocker > Fix For: 9.0.0.CR1 > > Attachments: error.log > > > Start an infinispan server and run the following CLI command: > ./bin/ispn-cli.sh -c '/subsystem=datagrid-infinispan/cache-container=local:register-proto-schemas(file-names=[myFileWithSyntaxErrors.proto], file-contents=[kaboom])' > since the file has syntax errors it should still be placed in the ___protobuf_metadata cache and a myFileWithSyntaxErrors.proto.errors key should also be created. No exception should be thrown. Currently no key is written in cache and the NPE from the attached log happens. > When registering a proper file without syntax errors this works correctly. > The problem disappears if I disable global state persistence, so the cachestore seems to play a role in this. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7415) Immortal entries use EmbeddedExpirableMetadata instead of EmbeddedMetadata

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7415?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7415: ------------------------------- Description: The default lifespan and maxIdle are -1 to signal no expiration, but calling {{EmbeddedMetadata.Builder.lifespan\(x)}} with any value will make it create an {{EmbeddedExpirableMetadata}} instance. (was: The default lifespan and maxIdle are -1 to signal no expiration, but calling {{EmbeddedMetadata.Builder.lifespan(x)}} with any value will make it create an {{EmbeddedExpirableMetadata}} instance.) > Immortal entries use EmbeddedExpirableMetadata instead of EmbeddedMetadata > -------------------------------------------------------------------------- > > Key: ISPN-7415 > URL: https://issues.jboss.org/browse/ISPN-7415 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.CR1 > > > The default lifespan and maxIdle are -1 to signal no expiration, but calling {{EmbeddedMetadata.Builder.lifespan\(x)}} with any value will make it create an {{EmbeddedExpirableMetadata}} instance. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7415) Immortal entries use EmbeddedExpirableMetadata instead of EmbeddedMetadata

by Dan Berindei (JIRA)

Dan Berindei created ISPN-7415: ---------------------------------- Summary: Immortal entries use EmbeddedExpirableMetadata instead of EmbeddedMetadata Key: ISPN-7415 URL: https://issues.jboss.org/browse/ISPN-7415 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.0.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.0.0.CR1 The default lifespan and maxIdle are -1 to signal no expiration, but calling {{EmbeddedMetadata.Builder.lifespan(x)}} with any value will make it create an {{EmbeddedExpirableMetadata}} instance. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2017