[JBoss JIRA] (ISPN-4359) Provide an annotation driven way of declaring protobuf metadata
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4359?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-4359:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.1.0.Beta1
Resolution: Done
Integrated in master.
> Provide an annotation driven way of declaring protobuf metadata
> ---------------------------------------------------------------
>
> Key: ISPN-4359
> URL: https://issues.jboss.org/browse/ISPN-4359
> Project: Infinispan
> Issue Type: Feature Request
> Components: Marshalling
> Affects Versions: 7.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: jdg
> Fix For: 7.1.0.Beta1
>
>
> The main goal of this is to simply marshalling of java objects to protobuf using the Protostream library.
> Instead of providing a Protostream MessageMarshaller implementation and a proto schema file it would be nice to have an alternative way of just adding minimal annotations to a Java class (and its fields) to assist on the fly generation (via reflection) of the proto schema. The Protostream library should also infer the marshaller so it would not require a manually implemented one. The annotation should require minimal info (tag number) and the rest should be inferred based on common sense defaults (protobuf type, java collection type, collection element type ...) but should be possible to override. The auto-generated schema should be available to users and they should be able then to use it as reference if they need it to implement domain model classes and marshallers for other languages.
> The user should still be able to specify a manually created schema (besides the annotated classes) and in that case the Protostream library should check the auto-inferred schema against the provided one and ensure they match.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5016) Specify and document cache consistency guarantees
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5016?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5016:
------------------------------------
>> Overlapping operations can happen in any order
> What does 'happen' mean? I guess that eventually the state will be observed with those operations in certain order but does it mean that all threads will observe the writes in the same order? I think that JMM does not guarantee anything like that, and we should put emphasis on this if it's the case for Infinispan, too.
I think JMM does guarantee that, if you consider each cache entry to be a volatile variable.
>> Note that the transaction manager will hide the exception when the cache is registered as a synchronization (BATCH and NON_XA).
> Are you sure about this? I thought that write skew check will fire in prepare phase, and exceptions from prepare are not hidden neither in synchronization mode.
You're right, I'll remove it.
>> maxIdle behaves similarly, except the reference timestamps are from the last write OR read operation.
> We could reference here ISPN-3202, expiration through idle time is not correctly maintained in cache store.
Sure.
>> In transactional caches, it also suspends the current transaction, and the next read in the transaction will not see the value.
> Sounds a bit like you had to resume the transaction manually after putForExternal read.
I'll add "for the duration of the operation".
> Specify and document cache consistency guarantees
> -------------------------------------------------
>
> Key: ISPN-5016
> URL: https://issues.jboss.org/browse/ISPN-5016
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Core
> Affects Versions: 7.0.2.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> We can't simply use the consistency model defined by Java Specification and broaden it for whole cache (maybe the expression "can't" is too strong, but we definitely don't want to do that in some cases).
> By consistency guarantees/model I mean mostly in which order are
> writes allowed to be observed: and we can't boil it down to simply
> causal, PRAM or any other consistency model as writes can be observed as non-atomic in Infinispan.
> Infinispan documentation is quite scarce about that, the only trace I've
> found is in Glossarry [2] "Infinispan has traditionally followed ACID
> principles as far as possible, however an eventually consistent mode
> embracing BASE is on the roadmap."
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5016) Specify and document cache consistency guarantees
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-5016?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-5016:
-----------------------------------
{quote}Overlapping operations can happen in any order{quote}
What does 'happen' mean? I guess that eventually the state will be observed with those operations in certain order but does it mean that all threads will observe the writes in the same order? I think that JMM does not guarantee anything like that, and we should put emphasis on this if it's the case for Infinispan, too.
{quote}Note that the transaction manager will hide the exception when the cache is registered as a synchronization (BATCH and NON_XA).{quote}
Are you sure about this? I thought that write skew check will fire in prepare phase, and exceptions from prepare are not hidden neither in synchronization mode.
{quote}maxIdle behaves similarly, except the reference timestamps are from the last write OR read operation.{quote}
We could reference here ISPN-3202, expiration through idle time is not correctly maintained in cache store.
{quote}In transactional caches, it also suspends the current transaction, and the next read in the transaction will not see the value.{quote}
Sounds a bit like you had to resume the transaction manually after putForExternal read.
> Specify and document cache consistency guarantees
> -------------------------------------------------
>
> Key: ISPN-5016
> URL: https://issues.jboss.org/browse/ISPN-5016
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Core
> Affects Versions: 7.0.2.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> We can't simply use the consistency model defined by Java Specification and broaden it for whole cache (maybe the expression "can't" is too strong, but we definitely don't want to do that in some cases).
> By consistency guarantees/model I mean mostly in which order are
> writes allowed to be observed: and we can't boil it down to simply
> causal, PRAM or any other consistency model as writes can be observed as non-atomic in Infinispan.
> Infinispan documentation is quite scarce about that, the only trace I've
> found is in Glossarry [2] "Infinispan has traditionally followed ACID
> principles as far as possible, however an eventually consistent mode
> embracing BASE is on the roadmap."
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5089) Zero-divide ArithmeticException in org.infinispan.interceptors.CacheMgmtInterceptor.getAverageWriteTime()
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5089?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5089:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.1.0.Beta1
Resolution: Done
> Zero-divide ArithmeticException in org.infinispan.interceptors.CacheMgmtInterceptor.getAverageWriteTime()
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5089
> URL: https://issues.jboss.org/browse/ISPN-5089
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Environment: JDG 6.3.1 (Infinispan 6.1.1.Final) and the current master seems the same.
> Reporter: Osamu Nagano
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> There are occasional {{java.lang.ArithmeticException: / by zero}} in server.log. It seems a part collecting statistics for MBean and they were actually collecting such data by JMX.
> {noformat}
> 2014-12-15 12:32:00.283 ERROR [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-491) ISPN005009: Unexpected error before any request parameters read: io.netty.handler.codec.DecoderException: org.infinispan.server.hotrod.HotRodException: java.lang.ArithmeticException: / by zero
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:417) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:141) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:471) [infinispan.jar:6.1.1.Final-redhat-5]
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:341) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:327) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:116) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:494) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:461) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]
> Caused by: org.infinispan.server.hotrod.HotRodException: java.lang.ArithmeticException: / by zero
> at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:206) [infinispan.jar:6.1.1.Final-redhat-5]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:77) [infinispan.jar:6.1.1.Final-redhat-5]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:61) [infinispan.jar:6.1.1.Final-redhat-5]
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:362) [netty-all-4.0.18.Final-redhat-1.jar:4.0.18.Final-redhat-1]
> ... 12 more
> Caused by: java.lang.ArithmeticException: / by zero
> at org.infinispan.interceptors.CacheMgmtInterceptor.getAverageWriteTime(CacheMgmtInterceptor.java:294) [infinispan-core-6.1.1.Final-redhat-5.jar:6.1.1.Final-redhat-5]
> at org.infinispan.stats.StatsImpl.<init>(StatsImpl.java:48) [infinispan-core-6.1.1.Final-redhat-5.jar:6.1.1.Final-redhat-5]
> at org.infinispan.CacheImpl.getStats(CacheImpl.java:884) [infinispan-core-6.1.1.Final-redhat-5.jar:6.1.1.Final-redhat-5]
> at org.infinispan.AbstractDelegatingAdvancedCache.getStats(AbstractDelegatingAdvancedCache.java:173) [infinispan-core-6.1.1.Final-redhat-5.jar:6.1.1.Final-redhat-5]
> at org.infinispan.server.hotrod.HotRodDecoder.createStatsResponse(HotRodDecoder.scala:161) [infinispan.jar:6.1.1.Final-redhat-5]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeHeader(AbstractProtocolDecoder.scala:147) [infinispan.jar:6.1.1.Final-redhat-5]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:70) [infinispan.jar:6.1.1.Final-redhat-5]
> ... 14 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5088) Deleted entries from (FineGrained)AtomicMap reappear in subsequent transaction
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5088?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5088:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Deleted entries from (FineGrained)AtomicMap reappear in subsequent transaction
> ------------------------------------------------------------------------------
>
> Key: ISPN-5088
> URL: https://issues.jboss.org/browse/ISPN-5088
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.2.Final
> Reporter: Sanne Grinovero
> Assignee: William Burns
> Priority: Critical
> Labels: 7.0, for_OGM
> Fix For: 7.1.0.Beta1, 7.0.3.Final
>
> Attachments: Testcase-ISPN-5088.patch
>
>
> After a {{FineGrainedAtomicMap}} containing some data is deleted in a transaction, but then in the same transaction it's re-created, the next transaction will be able to read the original data which it contained.
> Some pseudocode:
> {code}tx1.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k1, v1);
> tx1.commit()
> tx2.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k3, v3);
> AtomicMapLookup.removeAtomicMap( cache, cacheKey );
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k2,v2);
> tx2.commit()
> tx3.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.contains(k1) == false; // FAILS!
> tx3.commit();{code}
> Also applies apparently to a normal AtomicMap if using DIST_SYNC.
> I'm attaching a full test, which results in:
> {noformat}
> Failed tests:
> RepeatableReadFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> FineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistRepeatableReadFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistRepeatableReadAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> Tests run: 5636, Failures: 6, Errors: 0, Skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5104) Infinite loop in TransactionAwareCloseableIterator when iterating through cache...
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5104?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5104:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3175
> Infinite loop in TransactionAwareCloseableIterator when iterating through cache...
> ----------------------------------------------------------------------------------
>
> Key: ISPN-5104
> URL: https://issues.jboss.org/browse/ISPN-5104
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 7.0.2.Final
> Reporter: Christian Niessner
> Assignee: William Burns
>
> Hi,
> i have some testing code that iterates through a cache and validates all data in this cache for consistency.
> The reduced code is:
> TransactionManager tm = cache.getAdvancedCache().getTransactionManager();
> tm.begin();
> try {
> for (Entry<Object,Object> entry : metadataCache.entrySet()) {
> // validation code omitted...
> }
> } finally {
> tm.commit();
> }
> In some circumstances the iteration starts returning the same Entry every time. I stepped into the code and the value is returned from:
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> This code block is commented with:
> "// We do a last check to make sure no additional values were added to our context while iterating"
> And for me it seems that the value returned here never gets added to the "seenContextKeys" Set and so the iterator is always returning the same key.
> Maybe a simple "seenContextKeys.add(lookedUpEntry.getKey())" next to Line 70 would fix this issue. Maybe even a 'break' could make sense here because is there the need to walk through the entire list if we have found a candidate?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5016) Specify and document cache consistency guarantees
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5016?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5016:
------------------------------------
I have written a wiki page on consistency guarantees:
https://github.com/infinispan/infinispan/wiki/Consistency-guarantees-in-I...
It documents the current implementation, including things that we plan to fix soon, and it doesn't cover possible future improvements except for linking to some issues in JIRA.
> Specify and document cache consistency guarantees
> -------------------------------------------------
>
> Key: ISPN-5016
> URL: https://issues.jboss.org/browse/ISPN-5016
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Core
> Affects Versions: 7.0.2.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> We can't simply use the consistency model defined by Java Specification and broaden it for whole cache (maybe the expression "can't" is too strong, but we definitely don't want to do that in some cases).
> By consistency guarantees/model I mean mostly in which order are
> writes allowed to be observed: and we can't boil it down to simply
> causal, PRAM or any other consistency model as writes can be observed as non-atomic in Infinispan.
> Infinispan documentation is quite scarce about that, the only trace I've
> found is in Glossarry [2] "Infinispan has traditionally followed ACID
> principles as far as possible, however an eventually consistent mode
> embracing BASE is on the roadmap."
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5016) Specify and document cache consistency guarantees
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5016?page=com.atlassian.jira.plugin.... ]
Work on ISPN-5016 started by Dan Berindei.
------------------------------------------
> Specify and document cache consistency guarantees
> -------------------------------------------------
>
> Key: ISPN-5016
> URL: https://issues.jboss.org/browse/ISPN-5016
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Core
> Affects Versions: 7.0.2.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> We can't simply use the consistency model defined by Java Specification and broaden it for whole cache (maybe the expression "can't" is too strong, but we definitely don't want to do that in some cases).
> By consistency guarantees/model I mean mostly in which order are
> writes allowed to be observed: and we can't boil it down to simply
> causal, PRAM or any other consistency model as writes can be observed as non-atomic in Infinispan.
> Infinispan documentation is quite scarce about that, the only trace I've
> found is in Glossarry [2] "Infinispan has traditionally followed ACID
> principles as far as possible, however an eventually consistent mode
> embracing BASE is on the roadmap."
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5104) Infinite loop in TransactionAwareCloseableIterator when iterating through cache...
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5104?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5104:
--------------------------------
Status: Open (was: New)
> Infinite loop in TransactionAwareCloseableIterator when iterating through cache...
> ----------------------------------------------------------------------------------
>
> Key: ISPN-5104
> URL: https://issues.jboss.org/browse/ISPN-5104
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 7.0.2.Final
> Reporter: Christian Niessner
>
> Hi,
> i have some testing code that iterates through a cache and validates all data in this cache for consistency.
> The reduced code is:
> TransactionManager tm = cache.getAdvancedCache().getTransactionManager();
> tm.begin();
> try {
> for (Entry<Object,Object> entry : metadataCache.entrySet()) {
> // validation code omitted...
> }
> } finally {
> tm.commit();
> }
> In some circumstances the iteration starts returning the same Entry every time. I stepped into the code and the value is returned from:
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> This code block is commented with:
> "// We do a last check to make sure no additional values were added to our context while iterating"
> And for me it seems that the value returned here never gets added to the "seenContextKeys" Set and so the iterator is always returning the same key.
> Maybe a simple "seenContextKeys.add(lookedUpEntry.getKey())" next to Line 70 would fix this issue. Maybe even a 'break' could make sense here because is there the need to walk through the entire list if we have found a candidate?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (ISPN-5104) Infinite loop in TransactionAwareCloseableIterator when iterating through cache...
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5104?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-5104:
-----------------------------------
Assignee: William Burns
> Infinite loop in TransactionAwareCloseableIterator when iterating through cache...
> ----------------------------------------------------------------------------------
>
> Key: ISPN-5104
> URL: https://issues.jboss.org/browse/ISPN-5104
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 7.0.2.Final
> Reporter: Christian Niessner
> Assignee: William Burns
>
> Hi,
> i have some testing code that iterates through a cache and validates all data in this cache for consistency.
> The reduced code is:
> TransactionManager tm = cache.getAdvancedCache().getTransactionManager();
> tm.begin();
> try {
> for (Entry<Object,Object> entry : metadataCache.entrySet()) {
> // validation code omitted...
> }
> } finally {
> tm.commit();
> }
> In some circumstances the iteration starts returning the same Entry every time. I stepped into the code and the value is returned from:
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> This code block is commented with:
> "// We do a last check to make sure no additional values were added to our context while iterating"
> And for me it seems that the value returned here never gets added to the "seenContextKeys" Set and so the iterator is always returning the same key.
> Maybe a simple "seenContextKeys.add(lookedUpEntry.getKey())" next to Line 70 would fix this issue. Maybe even a 'break' could make sense here because is there the need to walk through the entire list if we have found a candidate?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months