[JBoss JIRA] (ISPN-9036) Parameterized branding for C++
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9036?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9036:
----------------------------------
Sprint: Sprint 9.3.0.Alpha1, Sprint 9.3.0.Beta1, Sprint 9.3.0.CR1, Sprint 9.3.0.Final, Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1 (was: Sprint 9.3.0.Alpha1, Sprint 9.3.0.Beta1, Sprint 9.3.0.CR1, Sprint 9.3.0.Final, Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0)
> Parameterized branding for C++
> ------------------------------
>
> Key: ISPN-9036
> URL: https://issues.jboss.org/browse/ISPN-9036
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Tristan Tarrant
> Assignee: Vittorio Rigamonti
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-9382) Jenkins release pipeline should handle multiple branches and reversioning
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9382?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9382:
----------------------------------
Sprint: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1 (was: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0)
> Jenkins release pipeline should handle multiple branches and reversioning
> -------------------------------------------------------------------------
>
> Key: ISPN-9382
> URL: https://issues.jboss.org/browse/ISPN-9382
> Project: Infinispan
> Issue Type: Enhancement
> Components: Build
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 9.4.5.Final
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-8861) DIST Iteration shouldn't go remote when a shared cache store is present
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8861?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8861:
----------------------------------
Sprint: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1 (was: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0)
> DIST Iteration shouldn't go remote when a shared cache store is present
> -----------------------------------------------------------------------
>
> Key: ISPN-8861
> URL: https://issues.jboss.org/browse/ISPN-8861
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 9.4.5.Final
>
>
> When a user runs a distributed iteration operation with a shared cache store, this shouldn't go remote as the local node would have all the data available to it. This is similar to the optimization when we don't go remote if the current node is an owner for all required segments.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-4075) State transfer should preserve the creation timestamp of entries
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-4075?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4075:
----------------------------------
Sprint: Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1 (was: Sprint 10.0.0.Alpha2)
> State transfer should preserve the creation timestamp of entries
> ----------------------------------------------------------------
>
> Key: ISPN-4075
> URL: https://issues.jboss.org/browse/ISPN-4075
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta1, 10.0.0.Final
>
>
> State transfer inserts values with the current time as the creation time. Since the entries store the expected lifespan and not the expected expiration time, entries on the receiving node could expire much later than intended.
> The argument probably doesn't apply to the timestamp of the last usage. Since state transfer process could be interpreted as a reader, it should be fine to extend the update the time of the last usage both on the sending node and on the receiving node.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-8124) Create Lean Infinispan Server
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8124?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8124:
----------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2)
> Create Lean Infinispan Server
> -----------------------------
>
> Key: ISPN-8124
> URL: https://issues.jboss.org/browse/ISPN-8124
> Project: Infinispan
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 9.1.0.Final
> Reporter: Ryan Emerson
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> We need to create an infinispan server that utilises the minimum number of dependencies during run time. This is in order to reduce the server's memory footprint as much as possible. The resulting server will have the following characteristics:
> * Based upon jboss-modules
> * Mostly compatible with existing standalone configuration
> * Expose management operations via Jolokia
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-8535) Rest API redesign
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8535?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8535:
----------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2)
> Rest API redesign
> -----------------
>
> Key: ISPN-8535
> URL: https://issues.jboss.org/browse/ISPN-8535
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
> Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
> * Create a cache: POST /rest/caches
> * Delete a cache: DELETE /rest/caches/myCache
> * Create a template: POST /rest/templates
> * Delete a template: DELETE /rest/templates/myTemplate
> * Create an entry: POST /rest/caches/myCache/1
> * Create a counter: POST /rest/counters
> * Get a counter value: GET /rest/counters/mycounter
> * Increment a counter: GET /rest/counters/mycounter?action=increment
> * Search a cache: GET /rest/caches/myCache?action=search
> * Create a script: POST /rest/scripts/
> * Get a script source: GET /rest/scritps/myScript
> * Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
> * Stop individual servers and the full cluster
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-9366) Cache.size optimizations
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9366?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9366:
----------------------------------
Sprint: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1 (was: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0)
> Cache.size optimizations
> ------------------------
>
> Key: ISPN-9366
> URL: https://issues.jboss.org/browse/ISPN-9366
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 9.4.5.Final
>
>
> Now that we have a segmented data container and segmented store we can add optimizations for the Cache.size operation in various configurations.
> If a store is configured, passivation must be disabled for any of these optimizations related to stores to work
> # Shared store can just invoke Store.size
> # No store & no expired entries can invoke DataContainer.sizeIncludingExpired(IntSet)
> # Non shared store can invoke Store.size(IntSet)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-9572) Configuration parser support for multiple cache-containers
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9572?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9572:
----------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2)
> Configuration parser support for multiple cache-containers
> ----------------------------------------------------------
>
> Key: ISPN-9572
> URL: https://issues.jboss.org/browse/ISPN-9572
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> The embedded configuration parser should allow parsing multiple <cache-container> elements, each one identified by a unique name.
> All cache-containers should share the same thread pools and transports.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years