February 2014 - infinispan-issues

[JBoss JIRA] (ISPN-3992) ReplSyncDistributedExecutorTest.testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout fails randomly

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3992: --------------------------------- Summary: ReplSyncDistributedExecutorTest.testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout fails randomly Key: ISPN-3992 URL: https://issues.jboss.org/browse/ISPN-3992 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Affects Versions: 6.0.1.Final Reporter: Pedro Ruivo Assignee: Dan Berindei Fix For: 7.0.0.Alpha1, 7.0.0.Final org.infinispan.distexec.ReplSyncDistributedExecutorTest.testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout http://ci.infinispan.org/viewLog.html?buildId=6518&tab=buildResultsDiv&bu... -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3991) DistSyncTx1PCL1FuncTest.testBackupOwnerInvalidatesL1WhenPrimaryIsUnaware fails randomly

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3991: --------------------------------- Summary: DistSyncTx1PCL1FuncTest.testBackupOwnerInvalidatesL1WhenPrimaryIsUnaware fails randomly Key: ISPN-3991 URL: https://issues.jboss.org/browse/ISPN-3991 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Affects Versions: 6.0.1.Final Reporter: Pedro Ruivo Assignee: Dan Berindei Fix For: 7.0.0.Alpha1, 7.0.0.Final org.infinispan.distribution.DistSyncTx1PCL1FuncTest.testBackupOwnerInvalidatesL1WhenPrimaryIsUnaware http://ci.infinispan.org/viewLog.html?buildId=5960&tab=buildResultsDiv&bu... -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3990) AtomicMapAPITest.testConcurrentTx fails randomly

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3990: --------------------------------- Summary: AtomicMapAPITest.testConcurrentTx fails randomly Key: ISPN-3990 URL: https://issues.jboss.org/browse/ISPN-3990 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Affects Versions: 6.0.1.Final Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 7.0.0.Alpha1, 7.0.0.Final org.infinispan.atomic.AtomicMapAPITest.testConcurrentTx http://ci.infinispan.org/viewLog.html?buildId=5946&tab=buildResultsDiv&bu... --- org.infinispan.atomic.RepeatableReadAtomicMapAPITest.testConcurrentTx http://ci.infinispan.org/viewLog.html?buildId=6518&tab=buildResultsDiv&bu... -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3989) L1StateTransferRemovesValueTest.testStateTransferWithL1InvalidationAboutToBeCommitted fails randomly

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3989: --------------------------------- Summary: L1StateTransferRemovesValueTest.testStateTransferWithL1InvalidationAboutToBeCommitted fails randomly Key: ISPN-3989 URL: https://issues.jboss.org/browse/ISPN-3989 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Affects Versions: 6.0.1.Final Reporter: Pedro Ruivo Assignee: Dan Berindei Fix For: 7.0.0.Alpha1, 7.0.0.Final org.infinispan.distribution.rehash.L1StateTransferRemovesValueTest.testStateTransferWithL1InvalidationAboutToBeCommitted http://ci.infinispan.org/viewLog.html?buildId=5946&tab=buildResultsDiv&bu... -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3988) AsyncStoreTest.testPutClearPut fails randomly

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3988: --------------------------------- Summary: AsyncStoreTest.testPutClearPut fails randomly Key: ISPN-3988 URL: https://issues.jboss.org/browse/ISPN-3988 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Affects Versions: 6.0.1.Final Reporter: Pedro Ruivo Assignee: Dan Berindei Fix For: 7.0.0.Alpha1, 7.0.0.Final org.infinispan.persistence.support.AsyncStoreTest.testPutClearPut http://ci.infinispan.org/viewLog.html?buildId=5946&tab=buildResultsDiv&bu... -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3987) Documentation refers to 'loaders' API

by Richard Kennard (JIRA)

Richard Kennard created ISPN-3987: ------------------------------------- Summary: Documentation refers to 'loaders' API Key: ISPN-3987 URL: https://issues.jboss.org/browse/ISPN-3987 Project: Infinispan Issue Type: Feature Request Reporter: Richard Kennard Assignee: Mircea Markus The documentation for Infinispan 6.x at... http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_filesystem_b... ...and possibly in other places, refers to the old API. Specifically it talks about 'loaders': {code} ConfigurationBuilder b = new ConfigurationBuilder(); b.loaders() .addSingleFileStore() .location("/tmp/myDataStore") .maxEntries(5000); {code} This seems to have been replaced by 'persistence' in 6.0? -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3718) Select which protobuf fields to index

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3718?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-3718: ------------------------------------- Yes, we need those options to bear more complex values than just a boolean. A little known aspect of protobuf options is they are very rich and can represent tuples and arrays also, even arrays of tuples or tuples of arrays. You get the idea :) So it would be perfectly doable even to completely emulate the whole HS indexing annotations. Here's a valid protobuf example of a field being annotated with an option: {code} message User { //... required string name = 3 [ (infinispan.Field) = { indexed : true, analyzed : false, some_array : [111, 222, 333], /* yes! even arrays of values */ } ]; //... } {code} The stuff between [ ] that follows a field declaration is the list of options attached to the field - its metadata/annotations. There can be multiple options, separated with comma. Unfortunately the protobuf syntax is not very nice and requires you to surround the option name in (). The value of the option is either a scalar value or a tuple surrounded by { }. The structure of the option has to be defined in advance (not shown here), so its usage can be validated by the protobuf schema compiler. Options values can have defaults, so the verbosity can be drastically reduced. So, would you consider this as a valid approach to define our indexing metadata? > Select which protobuf fields to index > ------------------------------------- > > Key: ISPN-3718 > URL: https://issues.jboss.org/browse/ISPN-3718 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > Currently we index all fields. An interesting idea is to use a custom protobuf Option (see 'Custom Options' section here https://developers.google.com/protocol-buffers/docs/proto) to indicate which message types and specifically which fields should be indexed, similar to Hibernate Search annotations. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3480) Use protoparser lib instead of relying on binary descriptors generated by protoc

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3480?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-3480: --------------------------------------- Each protobuf schema should be placed in its own entry in the registry. The protoparser should be invoked every time one of these entries is modified. > Use protoparser lib instead of relying on binary descriptors generated by protoc > -------------------------------------------------------------------------------- > > Key: ISPN-3480 > URL: https://issues.jboss.org/browse/ISPN-3480 > Project: Infinispan > Issue Type: Task > Components: Marshalling > Affects Versions: 6.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha1 > > > Use protoparser [1] for obtaining type metadata rather than relying one the binary descriptors generated by Google Prootbuf's protoc tool. > [1] https://github.com/square/protoparser -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3986) Infinispan server should use the management API (provided by JBossAS) to configure/manage the instance and piggypack the specific commands

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created ISPN-3986: -------------------------------------- Summary: Infinispan server should use the management API (provided by JBossAS) to configure/manage the instance and piggypack the specific commands Key: ISPN-3986 URL: https://issues.jboss.org/browse/ISPN-3986 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 Reporter: Wolf-Dieter Fink Assignee: Tristan Tarrant It should be possible to configure the instance in the same manner as this is possible with a JBossAS instance. The specific Infinispan commands should be added on top -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3942) HotRod client keep trying recover a connection to a cluster member after shutdown

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-3942: ----------------------------------- [~dan.berindei], Radim has a point. Note that this is another problem... In the client, the first attempt is performed in the owner (or primary owner, not sure) of the key, let's say server A. If A is down, the next attempt will use the RequestBalancingStrategy. However, this strategy can return the same server again. Why? because we didn't contact any live server so we don't have an updated list. Eventually, it will hit a live server and will get the updated list. In the meanwhile, the fix will avoid an extra wait. > HotRod client keep trying recover a connection to a cluster member after shutdown > --------------------------------------------------------------------------------- > > Key: ISPN-3942 > URL: https://issues.jboss.org/browse/ISPN-3942 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Environment: Infinispan server with HotRod client in server-client mode and replicated caches. > Reporter: Wolf-Dieter Fink > Assignee: Pedro Ruivo > Priority: Critical > Labels: clustered, hotrod, hotrod-java-client > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > Attachments: hotrod-client.log > > > If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed. > There is only a replicated cache configured. > From the server-logfile the new cluster view is established > 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered] > There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server. > This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason. -- 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, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2014