August 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10456) Remove ExternalPojo Interface and ExternallyMarshallable

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10456?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10456: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7182 > Remove ExternalPojo Interface and ExternallyMarshallable > -------------------------------------------------------- > > Key: ISPN-10456 > URL: https://issues.jboss.org/browse/ISPN-10456 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Affects Versions: 10.0.0.Beta4 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta5 > > > ExternallyMarshallable & ExternalPojo don't really make sense with the latest marshaller changes (ISPN-10354), as the Global & Persistence marshallers can only handle types they know about. Unknown types are always handled by the user marshaller and when JavaSerializationMarshaller is used (the default now) the user has to explicitly add classes to the white list. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10456) Remove ExternalPojo Interface and ExternallyMarshallable

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10456?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10456: -------------------------------- Status: Open (was: New) > Remove ExternalPojo Interface and ExternallyMarshallable > -------------------------------------------------------- > > Key: ISPN-10456 > URL: https://issues.jboss.org/browse/ISPN-10456 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Affects Versions: 10.0.0.Beta4 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta5 > > > ExternallyMarshallable & ExternalPojo don't really make sense with the latest marshaller changes (ISPN-10354), as the Global & Persistence marshallers can only handle types they know about. Unknown types are always handled by the user marshaller and when JavaSerializationMarshaller is used (the default now) the user has to explicitly add classes to the white list. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10354) Remove jboss-marshalling dependency from core

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10354?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10354: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta5 Resolution: Done > Remove jboss-marshalling dependency from core > --------------------------------------------- > > Key: ISPN-10354 > URL: https://issues.jboss.org/browse/ISPN-10354 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Marshalling > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta5 > > > Currently the core module has a hard dependency on jboss-marshalling regardless of what user marshaller is used, therefore we should make the necessary abstractions to remove this. This work compliments ISPN-9263 as it should not be necessary to have a jboss-marshalling jar on the classpath when utilising protostream marshalling. Furthermore, jboss-marshalling is not compatible with Quarkus, therefore this step is required in order for Infinispan embedded to be readily consumed via a Quarkus extension. > Removing jboss-marshalling will result in Serializable user types no longer being marshallable as default, therefore we should introduce a `infinispan-jboss-marshalling` jar that users can continue to utilise jboss-marshalling if they wish. Furthermore, it should also be possible for users to utilise {{JavaSerializationMarshaller}} as the configured user marshaller. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10432) Upgrade Protostream to 4.3.0.Alpha9

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10432?page=com.atlassian.jira.plugin... ] Ryan Emerson resolved ISPN-10432. --------------------------------- Resolution: Done > Upgrade Protostream to 4.3.0.Alpha9 > ----------------------------------- > > Key: ISPN-10432 > URL: https://issues.jboss.org/browse/ISPN-10432 > Project: Infinispan > Issue Type: Component Upgrade > Components: Remote Querying > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.0.0.Beta5 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10348) Migrate JDBC String based Cache Store from jdg-functional-tests to upstream

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10348?page=com.atlassian.jira.plugin... ] Ryan Emerson resolved ISPN-10348. --------------------------------- Fix Version/s: 10.0.0.Beta5 9.4.16.Final Resolution: Done > Migrate JDBC String based Cache Store from jdg-functional-tests to upstream > --------------------------------------------------------------------------- > > Key: ISPN-10348 > URL: https://issues.jboss.org/browse/ISPN-10348 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores, Test Suite - Core > Affects Versions: 10.0.0.Beta3, 9.4.15.Final > Reporter: Gustavo Lira e Silva > Assignee: Gustavo Lira e Silva > Priority: Major > Fix For: 10.0.0.Beta5, 9.4.16.Final > > > [jdg-functional-tests|https://github.com/infinispan/jdg-functional-tests] has some tests that needs to be migrate to upstream to have a unique test base. > QE team will wrap all upstream tests and run with arquillian, deploying with different servers and databases vendors and versions using jdg-functional-tests > Some changes on upstream tests will need to be made to be possible customize configurations like connections, jndi and so on. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10403) Add queries and async-cache functional tests

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10403?page=com.atlassian.jira.plugin... ] Ryan Emerson resolved ISPN-10403. --------------------------------- Resolution: Done > Add queries and async-cache functional tests > -------------------------------------------- > > Key: ISPN-10403 > URL: https://issues.jboss.org/browse/ISPN-10403 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite - Core, Test Suite - Query > Affects Versions: 9.4.15.Final > Reporter: Gustavo Lira e Silva > Assignee: Gustavo Lira e Silva > Priority: Major > Fix For: 10.0.0.Beta5, 9.4.16.Final > > > jdg-functional-tests project has some tests that needs to be migrate to upstream to have a unique test base. > QE team will wrap all upstream tests and run with arquillian, deploying with different servers and databases vendors and versions using jdg-functional-tests > Some changes on upstream tests will need to be made to be possible customize sme configurations -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10403) Add queries and async-cache functional tests

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10403?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10403: -------------------------------- Fix Version/s: 9.4.16.Final > Add queries and async-cache functional tests > -------------------------------------------- > > Key: ISPN-10403 > URL: https://issues.jboss.org/browse/ISPN-10403 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite - Core, Test Suite - Query > Affects Versions: 9.4.15.Final > Reporter: Gustavo Lira e Silva > Assignee: Gustavo Lira e Silva > Priority: Major > Fix For: 10.0.0.Beta5, 9.4.16.Final > > > jdg-functional-tests project has some tests that needs to be migrate to upstream to have a unique test base. > QE team will wrap all upstream tests and run with arquillian, deploying with different servers and databases vendors and versions using jdg-functional-tests > Some changes on upstream tests will need to be made to be possible customize sme configurations -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10403) Add queries and async-cache functional tests

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10403?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10403: -------------------------------- Fix Version/s: 10.0.0.Beta5 > Add queries and async-cache functional tests > -------------------------------------------- > > Key: ISPN-10403 > URL: https://issues.jboss.org/browse/ISPN-10403 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite - Core, Test Suite - Query > Affects Versions: 9.4.15.Final > Reporter: Gustavo Lira e Silva > Assignee: Gustavo Lira e Silva > Priority: Major > Fix For: 10.0.0.Beta5, 9.4.16.Final > > > jdg-functional-tests project has some tests that needs to be migrate to upstream to have a unique test base. > QE team will wrap all upstream tests and run with arquillian, deploying with different servers and databases vendors and versions using jdg-functional-tests > Some changes on upstream tests will need to be made to be possible customize sme configurations -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9422) Remove infinispan.server.*.workerThreads properties

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9422?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-9422. -------------------------------- Resolution: Done > Remove infinispan.server.*.workerThreads properties > --------------------------------------------------- > > Key: ISPN-9422 > URL: https://issues.jboss.org/browse/ISPN-9422 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Affects Versions: 9.4.0.CR3 > Reporter: Radim Vansa > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Beta5 > > > These properties are not documented ATM. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10032) unclear lifespan expiration lifespan value (seconds or UnixTime) for expiration for remote access with HotRod

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10032?page=com.atlassian.jira.plugin... ] Ryan Emerson resolved ISPN-10032. --------------------------------- Fix Version/s: 10.0.0.Beta5 Resolution: Done > unclear lifespan expiration lifespan value (seconds or UnixTime) for expiration for remote access with HotRod > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-10032 > URL: https://issues.jboss.org/browse/ISPN-10032 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.4.8.Final, 10.0.0.Beta2 > Reporter: Wolf-Dieter Fink > Assignee: Tristan Tarrant > Priority: Critical > Fix For: 10.0.0.Beta5 > > > The documentation of the org.infinispan.client.hotrod.RemoteCache API is confusing. The Class header explain that lifespan expiration will use Seconds or UnitTime depend on the given value but the methods with lifespan will not reflect that with a hint. > API document ([Upstream 9.4| https://docs.jboss.org/infinispan/9.4/apidocs/org/infinispan/client/hotro...] > contains the explanation as followed: > {quote} > *Eviction and expiration:* Unlike local Cache cache, which allows specifying time values with any granularity (as defined by TimeUnit), HotRod only supports seconds as time units. If a different time unit is used instead, HotRod will transparently convert it to seconds, using TimeUnit.toSeconds(long) method. This might result in loss of precision for values specified as nanos or milliseconds. > Another fundamental difference is in the case of lifespan (naturally does NOT apply for max idle): *If number of seconds is bigger than 30 days, this number of seconds is treated as UNIX time and so, represents the number of seconds since 1/1/1970.* > {quote} > But the behavior is different for different ISPN releases. When the specified lifespan value is bigger than 30 days: > - ISPN <=6.2: the value >30days is treated as UNIX time expiry > - ISPN >6.2 <=8.3: the specified value (the maximum is Integer.MAX_VALUE) is treated as lifespan for Hot Rod protocol 2.2 or later. > And as UNIX time expiry for Hot Rod protocol 2.1 or before. > - >8.3: the value >30days is treated as UNIX time expiry regardless of Hot Rod protocol version > According to the API for embedded mode and the method parameters the lifespan should be always treated as seconds, never as UNIX time -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2019