September 2016 - infinispan-issues

[JBoss JIRA] (ISPN-7048) Use an enumeration for the Hot Rod protocol version

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7048?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7048: ---------------------------------- Status: Open (was: New) > Use an enumeration for the Hot Rod protocol version > --------------------------------------------------- > > Key: ISPN-7048 > URL: https://issues.jboss.org/browse/ISPN-7048 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Tristan Tarrant > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1, 9.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7048) Use an enumeration for the Hot Rod protocol version

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7048?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7048: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4536 > Use an enumeration for the Hot Rod protocol version > --------------------------------------------------- > > Key: ISPN-7048 > URL: https://issues.jboss.org/browse/ISPN-7048 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Tristan Tarrant > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1, 9.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7048) Use an enumeration for the Hot Rod protocol version

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-7048: ------------------------------------- Summary: Use an enumeration for the Hot Rod protocol version Key: ISPN-7048 URL: https://issues.jboss.org/browse/ISPN-7048 Project: Infinispan Issue Type: Enhancement Components: Remote Protocols Reporter: Tristan Tarrant Assignee: Radoslav Husar Fix For: 9.0.0.Beta1, 9.0.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6935) Use Collection instead of Set

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6935?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6935: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Use Collection instead of Set > ----------------------------- > > Key: ISPN-6935 > URL: https://issues.jboss.org/browse/ISPN-6935 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.0.0.Beta1 > > > Currently the xManyCommand commands hold the keys in a set internally. During marshalling and splitting the set (when the command goes remote), we use {{HashSet}}. However, this has drawbacks: > a) if the set passed to command uses different means of equality than {{Object.hashCode()}} and {{Object.equals()}} we may lose some keys in the derived set - we don't inject dataContainer's keyEquivalence to the commands > b) as these sets are usually just iterated through (contains() is rare) it's less effective to use complex data structures as {{HashSet}} - plain {{ArrayList}} is sufficient. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6586) Run ReadOnlyKeyCommand and ReadOnlyManyCommand on owner

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6586?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6586: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Run ReadOnlyKeyCommand and ReadOnlyManyCommand on owner > ------------------------------------------------------- > > Key: ISPN-6586 > URL: https://issues.jboss.org/browse/ISPN-6586 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.0.0.Beta1 > > > Currently the remote value is fetched to origin and the function runs locally. That's not aligned with the idea of replicating only the operations, and suboptimal if the entry is bigger || more complex to marshall than the function return value. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6846) Script filter_failed_logs.sh doesn't work with the new test suite listeners

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6846?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6846: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/4447, https://github.com/infinispan/infinispan/pull/4568 (was: https://github.com/infinispan/infinispan/pull/4447) > Script filter_failed_logs.sh doesn't work with the new test suite listeners > --------------------------------------------------------------------------- > > Key: ISPN-6846 > URL: https://issues.jboss.org/browse/ISPN-6846 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.0.0.Alpha4 > > > CI uses {{filter_failed_logs.sh}} to find and filter the logs of failed tests in the Trace build. Unfortunately the script wasn't updated by ISPN-6364 (or ISPN-6609), so it doesn't find any failures. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6846) Script filter_failed_logs.sh doesn't work with the new test suite listeners

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6846?page=com.atlassian.jira.plugin.... ] Dan Berindei reopened ISPN-6846: -------------------------------- I updated the script to support both the new and the old style of reporting failed tests, but it is always always choosing the old style because it's only looking at the first 100 lines of the log. The script is unlikely to be used with another branch, so it doesn't really need to support the old style. > Script filter_failed_logs.sh doesn't work with the new test suite listeners > --------------------------------------------------------------------------- > > Key: ISPN-6846 > URL: https://issues.jboss.org/browse/ISPN-6846 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.0.0.Alpha4 > > > CI uses {{filter_failed_logs.sh}} to find and filter the logs of failed tests in the Trace build. Unfortunately the script wasn't updated by ISPN-6364 (or ISPN-6609), so it doesn't find any failures. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7047) Cloud cache store can check if container exists too early

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-7047?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-7047: ---------------------------------- Status: Open (was: New) > Cloud cache store can check if container exists too early > --------------------------------------------------------- > > Key: ISPN-7047 > URL: https://issues.jboss.org/browse/ISPN-7047 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.2.4.Final > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > > When container doesn't exits and cloud cache store creates new one, it check immediately if container is created. It can happen (observed several times on AWS S3), that container was created, but cache store failed with exception that it's not able to create cache store, as it checks S3 too early. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7047) Cloud cache store can check if container exists too early

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-7047?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-7047: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-cachestore-cloud/pull/9 > Cloud cache store can check if container exists too early > --------------------------------------------------------- > > Key: ISPN-7047 > URL: https://issues.jboss.org/browse/ISPN-7047 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.2.4.Final > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > > When container doesn't exits and cloud cache store creates new one, it check immediately if container is created. It can happen (observed several times on AWS S3), that container was created, but cache store failed with exception that it's not able to create cache store, as it checks S3 too early. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7047) Cloud cache store can check if container exists too early

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-7047: ------------------------------------- Summary: Cloud cache store can check if container exists too early Key: ISPN-7047 URL: https://issues.jboss.org/browse/ISPN-7047 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 8.2.4.Final Reporter: Vojtech Juranek Assignee: Vojtech Juranek When container doesn't exits and cloud cache store creates new one, it check immediately if container is created. It can happen (observed several times on AWS S3), that container was created, but cache store failed with exception that it's not able to create cache store, as it checks S3 too early. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2016