[JBoss JIRA] (ISPN-3125) SpringEmbeddedCacheManagerFactoryBean does not allow overrides when referencing config
by Mike Noordermeer (JIRA)
[ https://issues.jboss.org/browse/ISPN-3125?page=com.atlassian.jira.plugin.... ]
Mike Noordermeer updated ISPN-3125:
-----------------------------------
Description:
The SpringEmbeddedCacheManager contains the following comment:
bq. A user may further customize the SpringEmbeddedCacheManager's configuration using explicit setters on this FactoryBean. The properties thus defined will be applied either to the configuration loaded from Infinispan's configuration file in case one has been specified, or to a configuration initialized with Infinispan's default settings. Either way, the net effect is that explicitly set configuration properties take precedence over both those loaded from a configuration file as well as INFNISPAN's default settings.
In this current version, setting a configfile + overriding properties does not seem to be possible. This can also be seen in {{AbstractEmbeddedCacheManagerFactory.createBackingEmbeddedCacheManager()}}, where the overrides are only applied iff {{configurationFileLocation == null}}.
I made a little workaround to fix this issue, but it's a mess because the {{DefaultCacheManager}} does not seem to allow overriding values if it gets its config from an InputStream. The workaround is available at https://gist.github.com/MikeN123/5618297
It seems the same issue exists in {{InfinispanNamedEmbeddedCacheFactoryBean}}, there configuration overrides don't seem to be applied if {{configurationTemplateMode == DEFAULT}}, or {{configurationTemplateMode == NAMED}}, whereas the documentation says that should work.
was:
The SpringEmbeddedCacheManager contains the following comment:
bq. A user may further customize the SpringEmbeddedCacheManager's configuration using explicit setters on this FactoryBean. The properties thus defined will be applied either to the configuration loaded from Infinispan's configuration file in case one has been specified, or to a configuration initialized with Infinispan's default settings. Either way, the net effect is that explicitly set configuration properties take precedence over both those loaded from a configuration file as well as INFNISPAN's default settings.
In this current version, setting a configfile + overriding properties does not seem to be possible. This can also be seen in {{AbstractEmbeddedCacheManagerFactory.createBackingEmbeddedCacheManager()}}, where the overrides are only applied iff {{configurationFileLocation == null}}.
I made a little workaround to fix this issue, but it's a mess because the {{DefaultCacheManager}} does not seem to allow overriding values if it gets its config from an InputStream. The workaround is available at https://gist.github.com/MikeN123/5618297
> SpringEmbeddedCacheManagerFactoryBean does not allow overrides when referencing config
> --------------------------------------------------------------------------------------
>
> Key: ISPN-3125
> URL: https://issues.jboss.org/browse/ISPN-3125
> Project: Infinispan
> Issue Type: Bug
> Components: Spring integration
> Affects Versions: 5.3.0.Beta2
> Reporter: Mike Noordermeer
> Assignee: Mircea Markus
>
> The SpringEmbeddedCacheManager contains the following comment:
> bq. A user may further customize the SpringEmbeddedCacheManager's configuration using explicit setters on this FactoryBean. The properties thus defined will be applied either to the configuration loaded from Infinispan's configuration file in case one has been specified, or to a configuration initialized with Infinispan's default settings. Either way, the net effect is that explicitly set configuration properties take precedence over both those loaded from a configuration file as well as INFNISPAN's default settings.
> In this current version, setting a configfile + overriding properties does not seem to be possible. This can also be seen in {{AbstractEmbeddedCacheManagerFactory.createBackingEmbeddedCacheManager()}}, where the overrides are only applied iff {{configurationFileLocation == null}}.
> I made a little workaround to fix this issue, but it's a mess because the {{DefaultCacheManager}} does not seem to allow overriding values if it gets its config from an InputStream. The workaround is available at https://gist.github.com/MikeN123/5618297
> It seems the same issue exists in {{InfinispanNamedEmbeddedCacheFactoryBean}}, there configuration overrides don't seem to be applied if {{configurationTemplateMode == DEFAULT}}, or {{configurationTemplateMode == NAMED}}, whereas the documentation says that should work.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3125) SpringEmbeddedCacheManagerFactoryBean does not allow overrides when referencing config
by Mike Noordermeer (JIRA)
Mike Noordermeer created ISPN-3125:
--------------------------------------
Summary: SpringEmbeddedCacheManagerFactoryBean does not allow overrides when referencing config
Key: ISPN-3125
URL: https://issues.jboss.org/browse/ISPN-3125
Project: Infinispan
Issue Type: Bug
Components: Spring integration
Affects Versions: 5.3.0.Beta2
Reporter: Mike Noordermeer
Assignee: Mircea Markus
The SpringEmbeddedCacheManager contains the following comment:
bq. A user may further customize the SpringEmbeddedCacheManager's configuration using explicit setters on this FactoryBean. The properties thus defined will be applied either to the configuration loaded from Infinispan's configuration file in case one has been specified, or to a configuration initialized with Infinispan's default settings. Either way, the net effect is that explicitly set configuration properties take precedence over both those loaded from a configuration file as well as INFNISPAN's default settings.
In this current version, setting a configfile + overriding properties does not seem to be possible. This can also be seen in {{AbstractEmbeddedCacheManagerFactory.createBackingEmbeddedCacheManager()}}, where the overrides are only applied iff {{configurationFileLocation == null}}.
I made a little workaround to fix this issue, but it's a mess because the {{DefaultCacheManager}} does not seem to allow overriding values if it gets its config from an InputStream. The workaround is available at https://gist.github.com/MikeN123/5618297
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3108) Server endpoint compatibility enhancements
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3108?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3108:
-----------------------------------
Description:
Several TODOs:
- Transaction's lookedUpEntries, affected and lockedKeys should use equivalent collections
- -Change equivalent hash set to be based on JSR-166- <- done in https://github.com/infinispan/infinispan/commit/c714c7785a302cb228bc8f293...
- -Make CollectionFactory a per cache component and contain references to key/value equivalence- <- deleted since it complicates the code and does not really add value
- figure out a way to have comparable ByteArrayEquivalence implementation and uncomment tests
- -MetadataMortalCacheValue should extend MortalCacheValue, check others- <- That should not be the case because MetadataMortalCacheValue has metadata (which contains lifespan), and extending MortalCacheValue would add lifespan too, as separate reference, so MetadataMortalCacheValue extending MortalCacheValue would add an extra field to the object without any real benefit.
- EntryFactoryImpl.extractMetadata: "this is invoked from wrapEntryForPut and wrapEntryForReplace. Better make these two methods receive the metadata object directly from the caller, which is aware of these commands being MetadataAwareCommand, in order to avoid the not-so-nice instanceOf."
- Have `Builder lifespan(long time);` in Metadata builder interface and same for maxIdle.
- The simple cache.put(k,v) (and all other non-metadata bearing methods) create an immutable metadata object that always has the same (default) values for idle and expiry. This can be an single object instance instead of creating one per operation.
was:
Several TODOs:
- Transaction's lookedUpEntries, affected and lockedKeys should use equivalent collections
- -Change equivalent hash set to be based on JSR-166- <- done in https://github.com/infinispan/infinispan/commit/c714c7785a302cb228bc8f293...
- -Make CollectionFactory a per cache component and contain references to key/value equivalence- <- deleted since it complicates the code and does not really add value
- figure out a way to have comparable ByteArrayEquivalence implementation and uncomment tests
- MetadataMortalCacheValue should extend MortalCacheValue, check others...
- EntryFactoryImpl.extractMetadata: "this is invoked from wrapEntryForPut and wrapEntryForReplace. Better make these two methods receive the metadata object directly from the caller, which is aware of these commands being MetadataAwareCommand, in order to avoid the not-so-nice instanceOf."
- Have `Builder lifespan(long time);` in Metadata builder interface and same for maxIdle.
- The simple cache.put(k,v) (and all other non-metadata bearing methods) create an immutable metadata object that always has the same (default) values for idle and expiry. This can be an single object instance instead of creating one per operation.
> Server endpoint compatibility enhancements
> ------------------------------------------
>
> Key: ISPN-3108
> URL: https://issues.jboss.org/browse/ISPN-3108
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> Several TODOs:
> - Transaction's lookedUpEntries, affected and lockedKeys should use equivalent collections
> - -Change equivalent hash set to be based on JSR-166- <- done in https://github.com/infinispan/infinispan/commit/c714c7785a302cb228bc8f293...
> - -Make CollectionFactory a per cache component and contain references to key/value equivalence- <- deleted since it complicates the code and does not really add value
> - figure out a way to have comparable ByteArrayEquivalence implementation and uncomment tests
> - -MetadataMortalCacheValue should extend MortalCacheValue, check others- <- That should not be the case because MetadataMortalCacheValue has metadata (which contains lifespan), and extending MortalCacheValue would add lifespan too, as separate reference, so MetadataMortalCacheValue extending MortalCacheValue would add an extra field to the object without any real benefit.
> - EntryFactoryImpl.extractMetadata: "this is invoked from wrapEntryForPut and wrapEntryForReplace. Better make these two methods receive the metadata object directly from the caller, which is aware of these commands being MetadataAwareCommand, in order to avoid the not-so-nice instanceOf."
> - Have `Builder lifespan(long time);` in Metadata builder interface and same for maxIdle.
> - The simple cache.put(k,v) (and all other non-metadata bearing methods) create an immutable metadata object that always has the same (default) values for idle and expiry. This can be an single object instance instead of creating one per operation.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3108) Server endpoint compatibility enhancements
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3108?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3108:
-----------------------------------
Description:
Several TODOs:
- Transaction's lookedUpEntries, affected and lockedKeys should use equivalent collections
- -Change equivalent hash set to be based on JSR-166- <- done in https://github.com/infinispan/infinispan/commit/c714c7785a302cb228bc8f293...
- -Make CollectionFactory a per cache component and contain references to key/value equivalence- <- deleted since it complicates the code and does not really add value
- figure out a way to have comparable ByteArrayEquivalence implementation and uncomment tests
- MetadataMortalCacheValue should extend MortalCacheValue, check others...
- EntryFactoryImpl.extractMetadata: "this is invoked from wrapEntryForPut and wrapEntryForReplace. Better make these two methods receive the metadata object directly from the caller, which is aware of these commands being MetadataAwareCommand, in order to avoid the not-so-nice instanceOf."
- Have `Builder lifespan(long time);` in Metadata builder interface and same for maxIdle.
- The simple cache.put(k,v) (and all other non-metadata bearing methods) create an immutable metadata object that always has the same (default) values for idle and expiry. This can be an single object instance instead of creating one per operation.
was:
Several TODOs:
- Transaction's lookedUpEntries, affected and lockedKeys should use equivalent collections
- Change equivalent hash set to be based on JSR-166
- Make CollectionFactory a per cache component and contain references to key/value equivalence
- figure out a way to have comparable ByteArrayEquivalence implementation and uncomment tests
- MetadataMortalCacheValue should extend MortalCacheValue, check others...
- EntryFactoryImpl.extractMetadata: "this is invoked from wrapEntryForPut and wrapEntryForReplace. Better make these two methods receive the metadata object directly from the caller, which is aware of these commands being MetadataAwareCommand, in order to avoid the not-so-nice instanceOf."
- Have `Builder lifespan(long time);` in Metadata builder interface and same for maxIdle.
- The simple cache.put(k,v) (and all other non-metadata bearing methods) create an immutable metadata object that always has the same (default) values for idle and expiry. This can be an single object instance instead of creating one per operation.
> Server endpoint compatibility enhancements
> ------------------------------------------
>
> Key: ISPN-3108
> URL: https://issues.jboss.org/browse/ISPN-3108
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> Several TODOs:
> - Transaction's lookedUpEntries, affected and lockedKeys should use equivalent collections
> - -Change equivalent hash set to be based on JSR-166- <- done in https://github.com/infinispan/infinispan/commit/c714c7785a302cb228bc8f293...
> - -Make CollectionFactory a per cache component and contain references to key/value equivalence- <- deleted since it complicates the code and does not really add value
> - figure out a way to have comparable ByteArrayEquivalence implementation and uncomment tests
> - MetadataMortalCacheValue should extend MortalCacheValue, check others...
> - EntryFactoryImpl.extractMetadata: "this is invoked from wrapEntryForPut and wrapEntryForReplace. Better make these two methods receive the metadata object directly from the caller, which is aware of these commands being MetadataAwareCommand, in order to avoid the not-so-nice instanceOf."
> - Have `Builder lifespan(long time);` in Metadata builder interface and same for maxIdle.
> - The simple cache.put(k,v) (and all other non-metadata bearing methods) create an immutable metadata object that always has the same (default) values for idle and expiry. This can be an single object instance instead of creating one per operation.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3124) AtomicHashMap.put is not atomic with pessimistic locking
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3124?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3124:
-------------------------------
Workaround Description: Use {{AdvancedCache.lock}} to lock the atomic map key explicitly before modifying it.
Workaround: Workaround Exists
> AtomicHashMap.put is not atomic with pessimistic locking
> --------------------------------------------------------
>
> Key: ISPN-3124
> URL: https://issues.jboss.org/browse/ISPN-3124
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.3.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.CR1, 5.3.0.Final
>
>
> When the user calls {{AtomicHashMap.put(k, v)}}, {{AtomicHashMapProxy.getDeltaMapForWrite()}} first reads the atomic map in the invocation context, and only acquires a lock afterwards.
> Between the read and the lock, another transaction can write something to the atomic map, and that write will be lost.
--
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
12 years, 10 months