[JBoss JIRA] (ISPN-9964) Logging incompatibility when deploying modules on older versions of WildFly
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9964?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9964:
----------------------------------
Sprint: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32 (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31)
> Logging incompatibility when deploying modules on older versions of WildFly
> ---------------------------------------------------------------------------
>
> Key: ISPN-9964
> URL: https://issues.jboss.org/browse/ISPN-9964
> Project: Infinispan
> Issue Type: Bug
> Components: WildFly modules
> Affects Versions: 9.4.6.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 9.4.7.Final
>
>
> Older versions of Wildfly 7.1.x still utilise jboss-logging 3.1.x, whereas the 9.4.x branch uses 3.3.x. Jboss-logging 3.3.x introduced several new method signatures, which results in a {{NoSuchMethodError}} being thrown when infinispan is embedded on a older wildfly version. -To overcome this, it is necessary to make sure that only the method signatures found in both jboss-logging 3.1.x and 3.3.x are utilised.- Explicitly including the required version of jboss-logging in the wildfly-modules ensures that no discrepancy exists.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (ISPN-9962) Feature-packs should optionally depend on jdk-unsupported and sun.jdk
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9962?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9962:
----------------------------------
Sprint: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32 (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31)
> Feature-packs should optionally depend on jdk-unsupported and sun.jdk
> ---------------------------------------------------------------------
>
> Key: ISPN-9962
> URL: https://issues.jboss.org/browse/ISPN-9962
> Project: Infinispan
> Issue Type: Bug
> Components: WildFly modules
> Affects Versions: 10.0.0.Alpha3, 9.4.6.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 9.4.7.Final, 10.0.0.Beta1
>
>
> Currently our feature-packs depend on both "sun.jdk" and "jdk.unsupported" in an inconsistent manner. For the latest versions of Wildfly, we need to use the latter, whilst for older ones we need to use the former. Therefore, for all modules that require access to unsupported classes, we must provide an optional dependency on both of the above modules.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (ISPN-9932) Avoid creating MarshallableEntry instances if no CacheWriter enabled
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9932?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9932:
----------------------------------
Sprint: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32 (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31)
> Avoid creating MarshallableEntry instances if no CacheWriter enabled
> --------------------------------------------------------------------
>
> Key: ISPN-9932
> URL: https://issues.jboss.org/browse/ISPN-9932
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Affects Versions: 10.0.0.Alpha3
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> The (Dist)CacheWriterIntercepter is enabled if any loader/store is configured. The problem, is that the interceptor assumes that a CacheWriter is always configured. However, it is possible that only a CacheLoader has been configured, in which case when a write command visits the interceptor, MarshallableEntry instances are created unnecessarily in order to call the various PersistenceManager write operations.
> To avoid unnecessary allocations and the marshalling of key/value/metadata that is never stored, we should ensure that calls to PersistenceManager write methods are only called if a CacheWriter is actually configured.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (ISPN-9905) Rest store should retrieve created and lastUsed TS from server
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9905?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9905:
----------------------------------
Sprint: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32 (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31)
> Rest store should retrieve created and lastUsed TS from server
> --------------------------------------------------------------
>
> Key: ISPN-9905
> URL: https://issues.jboss.org/browse/ISPN-9905
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores, REST
> Affects Versions: 10.0.0.Alpha2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> Currently the rest store simply sets the created and lastUsed entries to the current time of the node loading an entry, instead we should retrieve this value from the server if fetchMetadata is true.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (ISPN-9915) JDBC publish Flowable should explicitly rollback connection
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9915?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9915:
----------------------------------
Sprint: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32 (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31)
> JDBC publish Flowable should explicitly rollback connection
> -----------------------------------------------------------
>
> Key: ISPN-9915
> URL: https://issues.jboss.org/browse/ISPN-9915
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 10.0.0.Alpha3, 9.4.6.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 9.4.7.Final, 10.0.0.Beta1
>
>
> The Flowable for the JDBC store publisher sets `autoCommit(false)` in order for pagination to work as expected, however we never explicitly call commit or rollback on the connection, therefore the exact behaviour is determined by the underlying connection pool. Instead we should explicitly call rollback() on the connection after the publisher has finished, because the operation is read only.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (ISPN-9843) RocksDBStore should not write entire MarshalledEntry as store value
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9843?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9843:
----------------------------------
Sprint: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32 (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31)
> RocksDBStore should not write entire MarshalledEntry as store value
> -------------------------------------------------------------------
>
> Key: ISPN-9843
> URL: https://issues.jboss.org/browse/ISPN-9843
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Affects Versions: 10.0.0.Alpha2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Alpha3
>
>
> Currently the RocksDBStore implementation writes an entire MarshalledEntry as the db's value. This is inefficient as it means the key is stored twice. Instead, a KeyValuePair of an entries value and metadata should be stored.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 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, DataGrid Sprint #31, DataGrid Sprint #32 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31)
> Lockdown query internals
> ------------------------
>
> Key: ISPN-9592
> URL: https://issues.jboss.org/browse/ISPN-9592
> Project: Infinispan
> Issue Type: Task
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> 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, 5 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, DataGrid Sprint #31, DataGrid Sprint #32 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31)
> 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.Beta4, 10.0.0.Final
>
>
> 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, 5 months