October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3663) Extend compatibility mode to store the binary value instead unmarshalling to java object

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-3663: ----------------------------------- Summary: Extend compatibility mode to store the binary value instead unmarshalling to java object Key: ISPN-3663 URL: https://issues.jboss.org/browse/ISPN-3663 Project: Infinispan Issue Type: Enhancement Components: Core API Affects Versions: 6.0.0.Beta2 Reporter: Adrian Nistor Assignee: Adrian Nistor Currently if compat mode is active we unmarshall the remote binary value into a java object and put this into the cache so embedded clients will be able to access a meaningful object. But this is not optimal as it will have to be serialized back to a byte array when remote clients get it and will also be to re-serialized when the put is replicated to another node. It's better to store the byte array that comes from the remote client directly and use the storeAsBinary / MarshalledValue mechanism to provide a java object to embedded clients. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3633: ------------------------------------- Yeah a small tweak to my test by disabling L1 and I can confirm that it misses the updated value after the state transfer. > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3662) Update Infinispan forge plugin to Forge 2

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-3662: -------------------------------------- Summary: Update Infinispan forge plugin to Forge 2 Key: ISPN-3662 URL: https://issues.jboss.org/browse/ISPN-3662 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño {quote}Check out the video describing Forge 2 and where we are headed: http://www.youtube.com/watch?v=Dpou-FWWatI {quote} Repo: https://github.com/forge/core#jboss-forge-20 -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3636) Chapters in the "Getting Started Guide" not delimited properly

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3636?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3636: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 6.0.0.CR2 Resolution: Done > Chapters in the "Getting Started Guide" not delimited properly > -------------------------------------------------------------- > > Key: ISPN-3636 > URL: https://issues.jboss.org/browse/ISPN-3636 > Project: Infinispan > Issue Type: Task > Reporter: Ion Savin > Assignee: Mircea Markus > Fix For: 6.0.0.CR2 > > > The chapters: > * Downloading and installing Infinispan > * Monitoring Infinispan > * Infinispan GUI demo > Are not delimited properly, they are appended at the end of the previous chapter and don't appear in the table of content. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3636) Chapters in the "Getting Started Guide" not delimited properly

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3636?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3636: ----------------------------------- Assignee: Ion Savin (was: Mircea Markus) > Chapters in the "Getting Started Guide" not delimited properly > -------------------------------------------------------------- > > Key: ISPN-3636 > URL: https://issues.jboss.org/browse/ISPN-3636 > Project: Infinispan > Issue Type: Task > Reporter: Ion Savin > Assignee: Ion Savin > Fix For: 6.0.0.CR2 > > > The chapters: > * Downloading and installing Infinispan > * Monitoring Infinispan > * Infinispan GUI demo > Are not delimited properly, they are appended at the end of the previous chapter and don't appear in the table of content. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3400) Upgrade to JCache 1.0.0-PFD

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3400?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3400: ----------------------------------- Summary: Upgrade to JCache 1.0.0-PFD (was: Upgrade to JCache 0.10) Fix Version/s: 6.0.0.CR2 6.0.0.Final (was: 6.1.0.Final) Description: JCache 1.0.0-PFD represents the Final Draft version of JSR-107. (was: JCache 0.10 represents the Public Draft Approval Ballot version of JSR-107.) > Upgrade to JCache 1.0.0-PFD > --------------------------- > > Key: ISPN-3400 > URL: https://issues.jboss.org/browse/ISPN-3400 > Project: Infinispan > Issue Type: Component Upgrade > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.0.CR2, 6.0.0.Final > > > JCache 1.0.0-PFD represents the Final Draft version of JSR-107. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3633: ------------------------------------- I was finally able to reproduce the problem. It has to be done as so. A - primary owner C - non owner # C gets value for k from A the current value and caches it in L1 # A is updating k with a new value in an explicit tx along with another entry that maps to C # A sends and completes prepare to C where it believes it is only updating the other entry (note commit is not yet sent) # State transfer starts and now C is the owner of k (note data has not been transferred yet) # A now commits the tx which causes an invalidation to be sent to C and the value to be marked as modified # State transfer finally is sent to C for data and is ignored. Actually thinking about this it may have a worse issue even when L1 is not enabled that the data cached is the old value as it wouldn't retrieve the value from the put command. I would need to test that still though. > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3661) Allow getting entry for key and suggesting it is placed into L1 cache

by Randall Hauch (JIRA)

Randall Hauch created ISPN-3661: ----------------------------------- Summary: Allow getting entry for key and suggesting it is placed into L1 cache Key: ISPN-3661 URL: https://issues.jboss.org/browse/ISPN-3661 Project: Infinispan Issue Type: Enhancement Reporter: Randall Hauch Assignee: Mircea Markus When running a distributed cache, some entries are far more popular and keeping them in L1 cache on all/most nodes would enable far better locality. This can be done with a custom hashing algorithm, except when the keys do not have enough information for the algorithm to know which entries should be placed into L1. Therefore, Infinispan should offer a way for clients to get an entry by key and simultaneously request that the resulting entry be placed into the local L1 cache. For example, perhaps {{get(K key, boolean cache)}} or even {{Cache.getL1cache().get(K key)}}. Here's a concrete example. ModeShape stores a tree structure in Infinispan, with keys that are basically UUIDs + other information. A common access pattern is to navigate from the root node, so it would be very useful to have the top nodes locally cached in L1 on each of the processes in the cluster (as they are accessed). ModeShape knows during access where in the tree the node is, and thus can decide the node is high enough in the tree that the node's entry be cached into L1. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3660) Allow CacheStores to access fields of data for which the schema is known

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-3660: ------------------------------------- Summary: Allow CacheStores to access fields of data for which the schema is known Key: ISPN-3660 URL: https://issues.jboss.org/browse/ISPN-3660 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Tristan Tarrant Assignee: Mircea Markus Currently cache stores read/write data from persistent storage as an opaque blob. Where we have access to the schema of data, we could expose this schema to the store so that it can write the single fields in a more appropriate fashion for the underlying persistence layer, e.g. write individual fields as columns in a relational database table or use the rich mapping of document stores (e.g. CouchDB, MongoDB). Additionally, stores should also be able to do the same for the entry's metadata (e.g. version, etc), as is already done for expiration. This technique can enable analysis / modification of data using the specific store tools (e.q. sqlplus, etc), or load pre-existing data to be served by the cache -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3300) PutForExternalRead doesn't supress exceptions with TotalOrder

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3300?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3300: ------------------------------ Fix Version/s: 6.0.0.CR2 > PutForExternalRead doesn't supress exceptions with TotalOrder > ------------------------------------------------------------- > > Key: ISPN-3300 > URL: https://issues.jboss.org/browse/ISPN-3300 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 6.0.0.CR2 > > > {{putForExternalRead}} is supposed to suppress any exceptions, but that doesn't work with Total Order caches. > Normally exceptions are suppressed in {{InvocationInterceptor.handleAll}} because the PFER PutKeyValueCommand has the FAIL_SILENTLY flag, but with TO the PFER is executed transactionally and the flag is not passed to the PrepareCommand. -- 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, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013