[JBoss JIRA] (ISPN-6152) Move the jdk8backported package down one level
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-6152:
-------------------------------------
Summary: Move the jdk8backported package down one level
Key: ISPN-6152
URL: https://issues.jboss.org/browse/ISPN-6152
Project: Infinispan
Issue Type: Task
Components: Core
Reporter: Tristan Tarrant
Assignee: William Burns
Fix For: 9.0.0.Alpha1
Move the jdk8backported package contents down 1 (also remove no longer needed classes after M/R removed)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6150) Drop Spring 3.x support
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-6150:
-------------------------------------
Summary: Drop Spring 3.x support
Key: ISPN-6150
URL: https://issues.jboss.org/browse/ISPN-6150
Project: Infinispan
Issue Type: Task
Components: Spring Integration
Reporter: Tristan Tarrant
Assignee: Sebastian Łaskawiec
Fix For: 9.0.0.Alpha1
Spring 3.x will be EOLed on 2016/12/31
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6149) Management console - refresh button on cluster detail page doesn't work properly
by Roman Macor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6149?page=com.atlassian.jira.plugin.... ]
Roman Macor updated ISPN-6149:
------------------------------
Description:
Clusters tab -> click on cluster
Actions -> stop -> wait for cluster to stop -> refresh
- cluster status doesn't change (should be "stopped"), after pressing refresh again cluster status disappears
Another issue:
- Pressing refresh repeatably results in nodes being displayed more than once (please see attached screenshot)
was:
Clusters tab -> click on cluster
Actions -> stop -> wait for cluster to stop -> refresh
- cluster status doesn't change (should be "stopped"), after pressing refresh again cluster status disappears
Another issue:
Pressing refresh repeatably results in nodes being displayed more than once (please see attached screenshot)
> Management console - refresh button on cluster detail page doesn't work properly
> --------------------------------------------------------------------------------
>
> Key: ISPN-6149
> URL: https://issues.jboss.org/browse/ISPN-6149
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
> Attachments: Screenshot-refresh.png
>
>
> Clusters tab -> click on cluster
> Actions -> stop -> wait for cluster to stop -> refresh
> - cluster status doesn't change (should be "stopped"), after pressing refresh again cluster status disappears
> Another issue:
> - Pressing refresh repeatably results in nodes being displayed more than once (please see attached screenshot)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6149) Management console - refresh button on cluster detail page doesn't work properly
by Roman Macor (JIRA)
Roman Macor created ISPN-6149:
---------------------------------
Summary: Management console - refresh button on cluster detail page doesn't work properly
Key: ISPN-6149
URL: https://issues.jboss.org/browse/ISPN-6149
Project: Infinispan
Issue Type: Bug
Components: Console
Reporter: Roman Macor
Assignee: Vladimir Blagojevic
Attachments: Screenshot-refresh.png
Clusters tab -> click on cluster
Actions -> stop -> wait for cluster to stop -> refresh
- cluster status doesn't change (should be "stopped"), after pressing refresh again cluster status disappears
Another issue:
Pressing refresh repeatably results in nodes being displayed more than once (please see attached screenshot)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6128) Expose ProtoBuf Manager through DMR
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6128?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-6128:
--------------------------------
Fix Version/s: 8.2.0.CR1
> Expose ProtoBuf Manager through DMR
> -----------------------------------
>
> Key: ISPN-6128
> URL: https://issues.jboss.org/browse/ISPN-6128
> Project: Infinispan
> Issue Type: Task
> Components: Remote Querying, Server
> Reporter: Tristan Tarrant
> Assignee: Adrian Nistor
> Fix For: 8.2.0.CR1, 8.2.0.Final
>
>
> The ProtoBuf Manager should be exposed through the DMR as a child resource under cache-container nodes. The resource should expose a number of operations to list, get, set, remove installed schemas.
> Example:
> .../cache-container=container/protobuf-schemas=PROTOBUF-SCHEMAS
> :list-schemas()
> :get-schema(name=myschema)
> :remove-schema(name=myschema)
> :set-schema(name=myschema, schema-source=...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-5876) Pre-commit cache invalidation creates stale cache vulnerability
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5876?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5876:
-----------------------------------------------
Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1273147|https://bugzilla.redhat.com/show_bug.cgi?id=1273147] from ASSIGNED to POST
> Pre-commit cache invalidation creates stale cache vulnerability
> ---------------------------------------------------------------
>
> Key: ISPN-5876
> URL: https://issues.jboss.org/browse/ISPN-5876
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.7.Final
> Reporter: Stephen Fikes
> Assignee: Galder Zamarreño
> Fix For: 5.2.15.Final, 8.1.0.Beta1, 8.1.0.Final
>
>
> In a cluster where Infinispan serves as the level 2 cache for Hibernate (configured for invalidation), because invalidation requests for modified entities are sent *before* database commit, it is possible for nodes receiving the invalidation request to perform eviction and then (due to "local" read requests) reload the evicted entities prior to the time the database commit takes place in the server where the entity was modified.
> Consequently, other servers in the cluster may contain data that remains stale until a subsequent change in another server or until the entity times out from lack of use.
> It isn't easy to write a testcase for this - it required manual intervention to reproduce - but can be seen with any entity class, cluster, etc. (at least using Oracle - results may vary with specific databases) so I've not attached a testcase. The issue can be seen/understood by code inspection (i.e. the timing of invalidation vs. database commit). That said, my test consisted of a two node cluster and I used Byteman rules to delay database commit of a change to an entity (with an optimistic version property) long enough in "server 1" for eviction to complete and a subsequent re-read (by a worker thread on behalf of an EJB) to take place in "server 2". Following the re-read in "server 2", I the database commit proceeds in "server 1" and "server 2" now has a stale copy of the entity in cache.
> One option is pessimistic locking which will block any read attempt until the DB commit completes. It is not feasible, however, for many applications to use pessimistic locking for all reads as this can have a severe impact on concurrency - and is the reason for using optimistic version control. But due to the early timing of invalidation broadcast (*before* database commit, while the data is not yet stale), optimistic locking is insufficient to guard against "permanently" stale data. We did see that some databases default to blocking repeatable reads even outside of transactions and without explicit lock requests. Oracle does not provide such a mode. So, all reads must be implemented to use pessimistic locks (which must be enclosed in explicit transactions - (b)locking reads are disallowed when autocommit=true in Oracle) and this could require significant effort (re-writes) to use pessimistic reads throughout - in addition to the performance issues this can introduce.
> If broadcast of an invalidation message always occurs *after* database commit, optimistic control attributes are sufficient to block attempts to write stale data and though a few failures may occur (as they would in a single server with multiple active threads), it can be known that the stale data will be removed in some finite period.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6147) Provide option to invalidate on commit
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6147?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6147:
-----------------------------------
Status: Open (was: New)
> Provide option to invalidate on commit
> --------------------------------------
>
> Key: ISPN-6147
> URL: https://issues.jboss.org/browse/ISPN-6147
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 5.2.14.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.2.15.Final
>
>
> For 5.2.x, provide an option to enable invalidation messages to be sent at commit time. This issue is related to ISPN-5876 where we changed the default behaviour to send invalidation messages at commit time. This created issues in the 5.2.x branch and instead it was decided that the fix should be reverted and instead provide an option to change the default behaviour to invalidate at commit time controlled by a system property.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-6147) Provide option to invalidate on commit
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6147?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6147:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3980
> Provide option to invalidate on commit
> --------------------------------------
>
> Key: ISPN-6147
> URL: https://issues.jboss.org/browse/ISPN-6147
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 5.2.14.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.2.15.Final
>
>
> For 5.2.x, provide an option to enable invalidation messages to be sent at commit time. This issue is related to ISPN-5876 where we changed the default behaviour to send invalidation messages at commit time. This created issues in the 5.2.x branch and instead it was decided that the fix should be reverted and instead provide an option to change the default behaviour to invalidate at commit time controlled by a system property.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months