August 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6711) Shared stores should only be purged from coordinator

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6711?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6711: ------------------------------- Status: Open (was: New) > Shared stores should only be purged from coordinator > ---------------------------------------------------- > > Key: ISPN-6711 > URL: https://issues.jboss.org/browse/ISPN-6711 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: Ryan Emerson > Fix For: 9.0.0.Beta1 > > > A shared store's data is accessible from all nodes. Therefore we should only have to purge from 1 node instead of all. Thus we should only purge shared stores if the node is the coordinator. This will reduce possible load on the stores by an amount equal to the number of nodes in worst case, which could be huge. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6844) Remove redundant enabled flag and disableInterceptor method from CacheWriter/Loader Interceptors

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6844?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6844: ------------------------------- Status: Open (was: New) > Remove redundant enabled flag and disableInterceptor method from CacheWriter/Loader Interceptors > ------------------------------------------------------------------------------------------------ > > Key: ISPN-6844 > URL: https://issues.jboss.org/browse/ISPN-6844 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > Currently both the CacheWriter and CacheLoader interceptors utilise a method disableInterceptor which sets a boolean flag to false. This method is only every called by PersistenceManagerImpl when removing the interceptor, at which point it should not be possible for any of the removed interceptor's methods to be executed. Therefore we should be able to remove this flag, associated checks and the disableInterceptor method without issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6711) Shared stores should only be purged from coordinator

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6711?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6711: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4488 > Shared stores should only be purged from coordinator > ---------------------------------------------------- > > Key: ISPN-6711 > URL: https://issues.jboss.org/browse/ISPN-6711 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: Ryan Emerson > Fix For: 9.0.0.Beta1 > > > A shared store's data is accessible from all nodes. Therefore we should only have to purge from 1 node instead of all. Thus we should only purge shared stores if the node is the coordinator. This will reduce possible load on the stores by an amount equal to the number of nodes in worst case, which could be huge. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6843) JdbcStringBasedStore process does not iterate entries in parallel

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6843?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6843: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4488 > JdbcStringBasedStore process does not iterate entries in parallel > ----------------------------------------------------------------- > > Key: ISPN-6843 > URL: https://issues.jboss.org/browse/ISPN-6843 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 9.0.0.Alpha2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > Current the process method is simply submitted to the executor and executed as one. Instead, the resultset of the query should be iterated in parallel like in JdbcBinaryStore. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6843) JdbcStringBasedStore process does not iterate entries in parallel

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6843?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6843: ------------------------------- Status: Open (was: New) > JdbcStringBasedStore process does not iterate entries in parallel > ----------------------------------------------------------------- > > Key: ISPN-6843 > URL: https://issues.jboss.org/browse/ISPN-6843 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 9.0.0.Alpha2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > Current the process method is simply submitted to the executor and executed as one. Instead, the resultset of the query should be iterated in parallel like in JdbcBinaryStore. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3940) Fine-grained authorization

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3940?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3940: ---------------------------------- Fix Version/s: (was: 9.0.0.Beta1) > Fine-grained authorization > -------------------------- > > Key: ISPN-3940 > URL: https://issues.jboss.org/browse/ISPN-3940 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Security > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > Add a way to set ACL per-entry, storing it in some additional security metadata so that only users belonging to certain roles can access it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6926) Server hangs on start

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6926?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6926: ------------------------------------ Description: Server testsuite is sometimes hanging with the stack attached. Arquillian starts the server, and after it does not respond, tries to kill it, and block. was: Server testsuite is hanging with the stack attached. Arquillian starts the server, and after it does not respond, tries to kill it, and block. > Server hangs on start > --------------------- > > Key: ISPN-6926 > URL: https://issues.jboss.org/browse/ISPN-6926 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Critical > Attachments: server, surefire > > > Server testsuite is sometimes hanging with the stack attached. Arquillian starts the server, and after it does not respond, tries to kill it, and block. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6927) Remove acquireRemoteLock and gtx from ClusteredGetCommand

by Radim Vansa (JIRA)

Radim Vansa created ISPN-6927: --------------------------------- Summary: Remove acquireRemoteLock and gtx from ClusteredGetCommand Key: ISPN-6927 URL: https://issues.jboss.org/browse/ISPN-6927 Project: Infinispan Issue Type: Task Components: Core Reporter: Radim Vansa Assignee: Radim Vansa Looking through the codebase, the acquireRemoteLock is never set, so we can remove this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6926) Server hangs on start

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6926?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6926: ------------------------------------ Summary: Server hangs on start (was: Server hang on start) > Server hangs on start > --------------------- > > Key: ISPN-6926 > URL: https://issues.jboss.org/browse/ISPN-6926 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Critical > Attachments: server, surefire > > > Server testsuite is hanging with the stack attached. Arquillian starts the server, and after it does not respond, tries to kill it, and block. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6906) Reduce dependency on JBoss Marshalling

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6906?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6906: ------------------------------------ [~galder.zamarreno] Slight correction: we never needed a separate marshaller for the key and for the value. We only need a separate marshaller when we change the classloader, because of the class/instance caching in RiverMarshaller. E.g. we start unmarshalling a {{CacheRpcCommand}} with the global marshaller, but then {{CacheRpcCommandExternalizer}} needs to switch to the cache marshaller once we know the cache name. Still, we use the same underlying byte array, there's no copying going on. > Reduce dependency on JBoss Marshalling > -------------------------------------- > > Key: ISPN-6906 > URL: https://issues.jboss.org/browse/ISPN-6906 > Project: Infinispan > Issue Type: Sub-task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.0.0.Final > > > Since its inception Infinispan has been using JBoss Marshalling to deal with all the marshalling needs. With some tweaking (e.g. hooking a custom ObjectTable instance), the JBoss Marshalling based Infinispan externalizer layer is able to produce tiny binary payloads but it has some problems partly due to JBoss Marshalling itself and partly due to our own implementation details: > JBoss Marshalling's objective has always been to try to produce a binary format that passes Java specification, but this is not a requirement for Infinispan. In fact, to reduce the payload size, Infinispan hooks at the ObjectTable level to produce minimal payload sizes. > On top of the mismatch problems mentioned above, JBoss Marshalling’s programming model is based around creating a marshaller, writing to it, and then finishing using it by discarding its context (same applies to unmarshalling). The problem here is two-fold: > * Both marshaller and unmarshaller are quite heavy objects, keeping context information such as references to instances appearing multiple times...etc, so constantly creating them is costly. So, to avoid wasting resources, we ended up adding thread locals that keep a number of marshaller/unmarshaller instances per thread (see ISPN-1815). These thread locals can potentially affect memory space (see user dev post). > * The second problem is the need to support reentrant marshalling calls when storing data in binary format. The need for reentrancy appears in situations like this: Imagine you have to marshall a PutKV command, so you start a marshaller and write some stuff. Then, you have store the key and value, but these are binary so they have to be transformed into binary format, so again a marshaller needs to be created and key/value information written, finish with the marshaller and then write the bytes in the command itself. So, there needs to be a way to start two marshallers without having finished the first one. This is the reason why the changes added in ISPN-1815 resulted in the thread local keeping a number of marshaller/unmarshaller instances rather than a single one. > Finally, for inter-node cluster communication and storing data in persistence layer, Infinispan is using JBoss Marshalling for both marshalling the types it knows about, e.g. internal data types, and types it does not know about, e.g. key and value types. This means that even if the marshaller is configurable, it’s not easy to switch to a different marshaller (see here for an example where we try to use a different marshaller). This problem is not present in Hot Rod Java clients since there JBoss Marshalling is purely used to marshall keys and values, so it’s very easy to test out a different marshaller. > With all this in mind, the following change recommendations can be made: > * For those types that we know about, marshall those manually in the most compact way possible. JBoss Marshalling codebase does a lot of these for encoding basic types (e.g. Strings, numbers)...etc, so we should be able to reuse them. > * Only rely on 3rd party marshalling libraries for types we don’t know about, e.g. key and value types (If these key/value types happen to be primitives, or primitive derivations (e.g. arrays), we should be able to optimise those too. So, you only rely on 3rd party marshalling libraries for custom unknown types.). The benefit here is the we decouple Infinispan from using JBoss Marshalling all over the place, making it easier to try different marshalling mechanisms. > * With JBoss Marshalling only used for unknown custom types, if the JBoss Marshalling marshaller implementation wants to use thread locals, that's fine, but then we effectively get rid of them except for custom types when JBoss Marshalling marshaller is used, plus we can switch/try different 3rd party marshallers which might be better suited. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2016