[JBoss JIRA] (ISPN-1239) Graceful shutdown should be supported
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-1239?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-1239:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> made a comment on [bug 919399|https://bugzilla.redhat.com/show_bug.cgi?id=919399]
Update from EAP 6.1.0.ER8 testing cycle: This issue was not seen during this cycle.
This can mean that it was either fixed unintentionally (maybe as a by-product of the Infinispan upgrade to 5.2.6.Final) or this issue just became rarer.
Either way, we decided not to close this issue.
> Graceful shutdown should be supported
> -------------------------------------
>
> Key: ISPN-1239
> URL: https://issues.jboss.org/browse/ISPN-1239
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Affects Versions: 5.0.0.FINAL
> Reporter: Manik Surtani
> Assignee: Dan Berindei
> Priority: Critical
> Labels: clean_shutdown, rehashing
> Fix For: 6.0.0.Final
>
>
> Currently, killing any node will result in a rehash. A mechanism for clean shutdown should also be supported, so that a rehash is *not* triggered. Useful when the entire cluster is being intentionally brought down.
> Need to think about how we do this; perhaps a LEAVE message that will prevent nodes triggering a rehash when a subsequent view change is detected. This could be done programmatically via a {{clean}} parameter to {{stop()}}, but we should explore alternatives here.
--
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, 4 months
[JBoss JIRA] (ISPN-2913) putForExternalRead leaves locks
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2913?page=com.atlassian.jira.plugin.... ]
Adrian Nistor reassigned ISPN-2913:
-----------------------------------
Assignee: Adrian Nistor (was: Mircea Markus)
> putForExternalRead leaves locks
> -------------------------------
>
> Key: ISPN-2913
> URL: https://issues.jboss.org/browse/ISPN-2913
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.1.Final
> Reporter: Sebastian Tusk
> Assignee: Adrian Nistor
> Priority: Critical
> Attachments: SebastianTusk_ISPN-2913.patch
>
>
> In TxDistributionInterceptor.remoteGetAndStoreInL1 locks are acquired. Without a transaction these locks are never released. The cache setup is Dist, Async, L1, 2 Nodes, 1 Owner, Optimistic Locking.
> In AbstractTxLockingInterceptor.visitGetKeyValueCommand locks are released explicitly if outside of transactions. I fixed this problem by doing the same in OptimisticLockingInterceptor.visitPutKeyValueCommand. It is very likely that this doesn't fix all problems. For instance OptimisticLockingInterceptor.visitPutMapCommand or PessimisticLockingInterceptor.
> Cache Config:
> <namedCache name="entity">
> <jmxStatistics enabled="true" />
>
> <clustering mode="dist">
> <stateTransfer fetchInMemoryState="false" timeout="20000" />
> <async />
> <l1 enabled="true" />
> <hash numOwners="1"/>
> </clustering>
> <locking isolationLevel="READ_COMMITTED"
> lockAcquisitionTimeout="15000" useLockStriping="false" />
>
> <eviction maxEntries="10000" strategy="LRU" />
> <expiration maxIdle="100000" wakeUpInterval="5000"/>
> <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" />
>
> <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/>
> </namedCache>
> Fixed OptimisticLockingInterceptor.visitPutKeyValueCommand:
> @Override
> public Object visitPutKeyValueCommand(InvocationContext ctx, PutKeyValueCommand command) throws Throwable {
> try {
> if (command.isConditional()) markKeyAsRead(ctx, command);
> return invokeNextInterceptor(ctx, command);
> } catch (Throwable te) {
> throw cleanLocksAndRethrow(ctx, te);
> } finally {
> //with putForExternalRead the value might be put into L1 without a transaction
> //we need to release any locks for these cases
> if (!ctx.isInTxScope()) lockManager.unlockAll(ctx);
> }
> }
--
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, 4 months
[JBoss JIRA] (ISPN-2281) Enable inter server endpoint communication in a compatibility mode
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2281?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2281:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1790, https://github.com/infinispan/infinispan/pull/1820 (was: https://github.com/infinispan/infinispan/pull/1790)
> Enable inter server endpoint communication in a compatibility mode
> ------------------------------------------------------------------
>
> Key: ISPN-2281
> URL: https://issues.jboss.org/browse/ISPN-2281
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Beta1, 5.3.0.Beta2, 5.3.0.Final
>
>
> Enable a compatibility mode that allows 3 main servers (Hot Rod, Memcached, REST ) and embedded mode (in-VM) to interact with each other. This would require some compatibility mode.
> Obviously, this needs to be testable, so possibly adding tests to the 'integration-tests' module. Need to demonstrate storing data in one “client” and accessing from others, modifying in others, and re-accessing in the first. Test should cover each of the 4 “clients” as the initial creator.
> When running in this mode, keys to be stored as Strings. In the case of REST and memcached, keys are strings anyway. In the case of Hot Rod, start the server with a flag to determine the encoding used (assuming the HR client uses Strings as well).
> For values - polymorphism between a MarshalledValue (in-VM), MemcachedValue, HotRodValue, RESTValue. Lazily convert from one to the other. May need a PortableValue as well, which contains all of the metadata of all of the value types above.
> May need to provide and encoding for values as well - to be able to make sense between Hot Rod byte array values and Strings in REST/memcached (base64?).
> In-VM may need registration of an Externalizer?
--
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, 4 months
[JBoss JIRA] (ISPN-3106) Remove support for non-concurrent non-transactional distributed caches
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-3106:
-----------------------------------
Summary: Remove support for non-concurrent non-transactional distributed caches
Key: ISPN-3106
URL: https://issues.jboss.org/browse/ISPN-3106
Project: Infinispan
Issue Type: Enhancement
Components: Configuration, Distributed Cache, Locking and Concurrency
Affects Versions: 5.3.0.Beta1
Reporter: Adrian Nistor
Assignee: Adrian Nistor
Fix For: 5.3.0.Beta2
LockingConfigurationBuilder.supportsConcurrentUpdates() and LockingConfiguration.supportsConcurrentUpdates() should be deprecated. This config option should be assumed true and support for the non-concurrent case should be dropped to simplify distribution and locking interceptor hierarchy.
--
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, 4 months
[JBoss JIRA] (ISPN-3105) Design query API for both embedded use and Java Hot Rod client
by Manik Surtani (JIRA)
[ https://issues.jboss.org/browse/ISPN-3105?page=com.atlassian.jira.plugin.... ]
Manik Surtani updated ISPN-3105:
--------------------------------
Description:
There are several parts to this JIRA.
1. We'd need a query API to be able to run queries on a cache. For example:
{{{
// Super-interface to Cache and RemoteCache
public interface BasicCache {
...
Set<?> runQuery(Filter f);
...
}
}}}
such that the same API can be used for remote (for the Hot Rod Java client) as well as embedded querying.
2. Since the approach we're using is effectively to look at the global data set and apply a series of filters, we'd need a {{FilterBuilder}} as well to create such filters. E.g.,
{{{
new FilterBuilder().matches("name", "QueenElizabeth").and().greaterThan("age", 65).build();
}}}
The Hibernate Search query DSL could probably be used for inspiration.
3. Further, we should still have an API that takes in Lucene Query objects - as per the existing Query API - but this would be for embedded mode only. E.g.,
{{{
public interface Cache {
...
Set<?> runLuceneQuery(LuceneQuery q);
...
}
}}}
4. Projections. We may also want to support projections. This needs thought. Again, Hibernate Search's APIs can provide inspiration.
was:
There are several parts to this JIRA.
1. We'd need a query API to be able to run queries on a cache. For example:
{{
// Super-interface to Cache and RemoteCache
public interface BasicCache {
...
Set<?> runQuery(Filter f);
...
}
}}
such that the same API can be used for remote (for the Hot Rod Java client) as well as embedded querying.
2. Since the approach we're using is effectively to look at the global data set and apply a series of filters, we'd need a {{FilterBuilder}} as well to create such filters. E.g.,
{{
new FilterBuilder().matches("name", "QueenElizabeth").and().greaterThan("age", 65).build();
}}
The Hibernate Search query DSL could probably be used for inspiration.
3. Further, we should still have an API that takes in Lucene Query objects - as per the existing Query API - but this would be for embedded mode only. E.g.,
{{
public interface Cache {
...
Set<?> runLuceneQuery(LuceneQuery q);
...
}
}}
4. Projections. We may also want to support projections. This needs thought. Again, Hibernate Search's APIs can provide inspiration.
> Design query API for both embedded use and Java Hot Rod client
> --------------------------------------------------------------
>
> Key: ISPN-3105
> URL: https://issues.jboss.org/browse/ISPN-3105
> Project: Infinispan
> Issue Type: Task
> Components: Querying
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Labels: remote-query
> Fix For: 6.0.0.Alpha2, 6.0.0.Final
>
>
> There are several parts to this JIRA.
> 1. We'd need a query API to be able to run queries on a cache. For example:
> {{{
> // Super-interface to Cache and RemoteCache
> public interface BasicCache {
> ...
> Set<?> runQuery(Filter f);
> ...
> }
> }}}
> such that the same API can be used for remote (for the Hot Rod Java client) as well as embedded querying.
> 2. Since the approach we're using is effectively to look at the global data set and apply a series of filters, we'd need a {{FilterBuilder}} as well to create such filters. E.g.,
> {{{
> new FilterBuilder().matches("name", "QueenElizabeth").and().greaterThan("age", 65).build();
> }}}
> The Hibernate Search query DSL could probably be used for inspiration.
> 3. Further, we should still have an API that takes in Lucene Query objects - as per the existing Query API - but this would be for embedded mode only. E.g.,
> {{{
> public interface Cache {
> ...
> Set<?> runLuceneQuery(LuceneQuery q);
> ...
> }
> }}}
> 4. Projections. We may also want to support projections. This needs thought. Again, Hibernate Search's APIs can provide inspiration.
--
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, 4 months
[JBoss JIRA] (ISPN-3105) Design query API for both embedded use and Java Hot Rod client
by Manik Surtani (JIRA)
[ https://issues.jboss.org/browse/ISPN-3105?page=com.atlassian.jira.plugin.... ]
Manik Surtani updated ISPN-3105:
--------------------------------
Description:
There are several parts to this JIRA.
1. We'd need a query API to be able to run queries on a cache. For example:
{code:java}
// Super-interface to Cache and RemoteCache
public interface BasicCache {
...
Set<?> runQuery(Filter f);
...
}
{code}
such that the same API can be used for remote (for the Hot Rod Java client) as well as embedded querying.
2. Since the approach we're using is effectively to look at the global data set and apply a series of filters, we'd need a {{FilterBuilder}} as well to create such filters. E.g.,
{code:java}
new FilterBuilder().matches("name", "QueenElizabeth").and().greaterThan("age", 65).build();
{code}
The Hibernate Search query DSL could probably be used for inspiration.
3. Further, we should still have an API that takes in Lucene Query objects - as per the existing Query API - but this would be for embedded mode only. E.g.,
{code:java}
public interface Cache {
...
Set<?> runLuceneQuery(LuceneQuery q);
...
}
{code}
4. Projections. We may also want to support projections. This needs thought. Again, Hibernate Search's APIs can provide inspiration.
was:
There are several parts to this JIRA.
1. We'd need a query API to be able to run queries on a cache. For example:
{{{
// Super-interface to Cache and RemoteCache
public interface BasicCache {
...
Set<?> runQuery(Filter f);
...
}
}}}
such that the same API can be used for remote (for the Hot Rod Java client) as well as embedded querying.
2. Since the approach we're using is effectively to look at the global data set and apply a series of filters, we'd need a {{FilterBuilder}} as well to create such filters. E.g.,
{{{
new FilterBuilder().matches("name", "QueenElizabeth").and().greaterThan("age", 65).build();
}}}
The Hibernate Search query DSL could probably be used for inspiration.
3. Further, we should still have an API that takes in Lucene Query objects - as per the existing Query API - but this would be for embedded mode only. E.g.,
{{{
public interface Cache {
...
Set<?> runLuceneQuery(LuceneQuery q);
...
}
}}}
4. Projections. We may also want to support projections. This needs thought. Again, Hibernate Search's APIs can provide inspiration.
> Design query API for both embedded use and Java Hot Rod client
> --------------------------------------------------------------
>
> Key: ISPN-3105
> URL: https://issues.jboss.org/browse/ISPN-3105
> Project: Infinispan
> Issue Type: Task
> Components: Querying
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Labels: remote-query
> Fix For: 6.0.0.Alpha2, 6.0.0.Final
>
>
> There are several parts to this JIRA.
> 1. We'd need a query API to be able to run queries on a cache. For example:
> {code:java}
> // Super-interface to Cache and RemoteCache
> public interface BasicCache {
> ...
> Set<?> runQuery(Filter f);
> ...
> }
> {code}
> such that the same API can be used for remote (for the Hot Rod Java client) as well as embedded querying.
> 2. Since the approach we're using is effectively to look at the global data set and apply a series of filters, we'd need a {{FilterBuilder}} as well to create such filters. E.g.,
> {code:java}
> new FilterBuilder().matches("name", "QueenElizabeth").and().greaterThan("age", 65).build();
> {code}
> The Hibernate Search query DSL could probably be used for inspiration.
> 3. Further, we should still have an API that takes in Lucene Query objects - as per the existing Query API - but this would be for embedded mode only. E.g.,
> {code:java}
> public interface Cache {
> ...
> Set<?> runLuceneQuery(LuceneQuery q);
> ...
> }
> {code}
> 4. Projections. We may also want to support projections. This needs thought. Again, Hibernate Search's APIs can provide inspiration.
--
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, 4 months
[JBoss JIRA] (ISPN-3105) Design query API for both embedded use and Java Hot Rod client
by Manik Surtani (JIRA)
[ https://issues.jboss.org/browse/ISPN-3105?page=com.atlassian.jira.plugin.... ]
Manik Surtani updated ISPN-3105:
--------------------------------
Labels: remote-query (was: )
Priority: Major (was: Blocker)
Description:
There are several parts to this JIRA.
1. We'd need a query API to be able to run queries on a cache. For example:
{{
// Super-interface to Cache and RemoteCache
public interface BasicCache {
...
Set<?> runQuery(Filter f);
...
}
}}
such that the same API can be used for remote (for the Hot Rod Java client) as well as embedded querying.
2. Since the approach we're using is effectively to look at the global data set and apply a series of filters, we'd need a {{FilterBuilder}} as well to create such filters. E.g.,
{{
new FilterBuilder().matches("name", "QueenElizabeth").and().greaterThan("age", 65).build();
}}
The Hibernate Search query DSL could probably be used for inspiration.
3. Further, we should still have an API that takes in Lucene Query objects - as per the existing Query API - but this would be for embedded mode only. E.g.,
{{
public interface Cache {
...
Set<?> runLuceneQuery(LuceneQuery q);
...
}
}}
4. Projections. We may also want to support projections. This needs thought. Again, Hibernate Search's APIs can provide inspiration.
was:This would be the API to be replicated/exposed for the remote query as well and a subset of what we currently expose through Lucene queries. Lucene queries would still be available through a different interface.
Estimated Difficulty: Medium
> Design query API for both embedded use and Java Hot Rod client
> --------------------------------------------------------------
>
> Key: ISPN-3105
> URL: https://issues.jboss.org/browse/ISPN-3105
> Project: Infinispan
> Issue Type: Task
> Components: Querying
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Labels: remote-query
> Fix For: 6.0.0.Alpha2, 6.0.0.Final
>
>
> There are several parts to this JIRA.
> 1. We'd need a query API to be able to run queries on a cache. For example:
> {{
> // Super-interface to Cache and RemoteCache
> public interface BasicCache {
> ...
> Set<?> runQuery(Filter f);
> ...
> }
> }}
> such that the same API can be used for remote (for the Hot Rod Java client) as well as embedded querying.
> 2. Since the approach we're using is effectively to look at the global data set and apply a series of filters, we'd need a {{FilterBuilder}} as well to create such filters. E.g.,
> {{
> new FilterBuilder().matches("name", "QueenElizabeth").and().greaterThan("age", 65).build();
> }}
> The Hibernate Search query DSL could probably be used for inspiration.
> 3. Further, we should still have an API that takes in Lucene Query objects - as per the existing Query API - but this would be for embedded mode only. E.g.,
> {{
> public interface Cache {
> ...
> Set<?> runLuceneQuery(LuceneQuery q);
> ...
> }
> }}
> 4. Projections. We may also want to support projections. This needs thought. Again, Hibernate Search's APIs can provide inspiration.
--
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, 4 months