[JBoss JIRA] (ISPN-9824) Unable to build Infinispan with JDK 11
by Vladimir Dosoudil (Jira)
Vladimir Dosoudil created ISPN-9824:
---------------------------------------
Summary: Unable to build Infinispan with JDK 11
Key: ISPN-9824
URL: https://issues.jboss.org/browse/ISPN-9824
Project: Infinispan
Issue Type: Bug
Components: Build
Affects Versions: 9.4.3.Final
Reporter: Vladimir Dosoudil
It's not able to build Infinispan with JDK 11.
Module infinispan-commons contains JDK specific classes which requires to be built in JDK 9+ (JDK 11 is LTS) but it's not able to build the whole Infinispan project with distribution profile related to fails on missing classes for infinispan-doclets module (referencing com.sun.javadoc*) using tools.jar which are not the part of JDK 9+ anymore. The failure is also on generating javadoc for infinispan-commons which uses sun.reflect.Reflection.getCallerClass which is discontinuing in JDK 11.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-9578) Move HR wire docs to contributing guide
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9578?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9578:
----------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Beta1 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final)
> Move HR wire docs to contributing guide
> ---------------------------------------
>
> Key: ISPN-9578
> URL: https://issues.jboss.org/browse/ISPN-9578
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Core
> Affects Versions: 9.4.0.CR3
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 9.4.5.Final
>
>
> The Hot Rod wire protocol has no place in the user guide. It should be moved to the contributing guide.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-2445) Safe shutdown - transfer data to other nodes
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-2445?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2445:
----------------------------------
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 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)
> Safe shutdown - transfer data to other nodes
> --------------------------------------------
>
> Key: ISPN-2445
> URL: https://issues.jboss.org/browse/ISPN-2445
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Matej Lazar
> Assignee: Dan Berindei
> Priority: Major
>
> Distributed cache should provide an configuration option to block shutdown until data from shutting down node is transferred to other nodes.
> This feature is useful if Infinispan is used as persistent storage.
> Without this option, in a cloud environment, where server node is deleted on scale down event, users are forced to use external storage, if they don't want to loose data.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-2575) Key Transformer registration is required on all nodes of the cluster, in case of custom keys
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2575:
----------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Beta1 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final)
> Key Transformer registration is required on all nodes of the cluster, in case of custom keys
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-2575
> URL: https://issues.jboss.org/browse/ISPN-2575
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Priority: Minor
> Fix For: 10.0.0.Beta1
>
> Attachments: ClusteredCacheTest.java
>
>
> The case is the following:
> I have a clustered cache on which I want to perform a search. I'm doing the following:
> I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception:
> java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer
> When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager.
> The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer()
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-9397) Check TX support for remote caches
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9397?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9397:
----------------------------------
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)
> Check TX support for remote caches
> ----------------------------------
>
> Key: ISPN-9397
> URL: https://issues.jboss.org/browse/ISPN-9397
> Project: Infinispan
> Issue Type: Bug
> Components: Hot Rod, Remote Protocols, Transactions
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> The {{RemoteCacheManager.getCache()}} methods would fail to return a transactional cache if the cache in server isn't transactional. It would throw an exception! {{NotTransactionalException}}?
> The user can fallback to the non transaction case, example
> {code:java}
> try {
> cache = remoteCacheManager.getCache("some-cache", TransactionMode.NON_XA);
> } catch(NotTransactionalException e) {
> cache = remoteCacheManager.getCache("some-cache", TransactionMode.NONE);
> }
> {code}
> In addition, some helper method can be added to the {{RemoteCacheManager}} to avoid dealing with exceptions:
> {code:java}
> boolean supportsTransactions(String cacheName);
> {code}
> simple example:
> {code:java}
> boolean txCache = remoteCacheManager.supportsTransactions("some-cache");
> remoteCacheManager.getCache("some-cache", txCache ? TransactionMode.NON_XA : TransactionMode.NONE);
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-9463) Provide API to enlist the resource with TransactionManager
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9463?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9463:
----------------------------------
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)
> Provide API to enlist the resource with TransactionManager
> ----------------------------------------------------------
>
> Key: ISPN-9463
> URL: https://issues.jboss.org/browse/ISPN-9463
> Project: Infinispan
> Issue Type: Enhancement
> Components: Hot Rod, Remote Protocols, Transactions
> Reporter: Ramesh Reddy
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> Currently, Infinispan will automatically enlist the transaction when a transaction is bound to the executing thread. However, in cases like Teiid where remote access to Infinispan access is wrapped with a resource-adapter (RAR) the resource adapter does the explicit enlisting or delisting. For this there needs to be API provided by Infinispan Cache like
> {code}
> RemoteCacheManager.getXaResource()
> {code}
> where it can access the XA resource.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-9592) Lockdown query internals
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9592?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9592:
----------------------------------
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)
> Lockdown query internals
> ------------------------
>
> Key: ISPN-9592
> URL: https://issues.jboss.org/browse/ISPN-9592
> Project: Infinispan
> Issue Type: Task
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Priority: Major
>
> Many things in query implementation are left public although they are very prone to creating insidious bugs if accessed externally. These are not proper extension points and should be made package local or provided strictly via SearchManagerImplementor.
> * Move SearchManager.purge(Class) method to SearchManagerImplementor
> * DefaultSearchWorkCreator should be moved to org.infinispan.query.backend and made package local
> * TransactionalEventTransactionContext is not used, can be removed, and its non-tx counterpart (NoTransactionContext) no longer has to be public
> * all public methods in QueryInterceptor must be reviewed and made package local ASAP
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-9620) Rolling Upgrade Marshaller Changes
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9620?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9620:
----------------------------------
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)
> Rolling Upgrade Marshaller Changes
> ----------------------------------
>
> Key: ISPN-9620
> URL: https://issues.jboss.org/browse/ISPN-9620
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Loaders and Stores
> Affects Versions: 9.4.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months