[JBoss JIRA] (ISPN-2280) Async cache store shutdown timeout default value should be -1
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-2280:
--------------------------------------
Summary: Async cache store shutdown timeout default value should be -1
Key: ISPN-2280
URL: https://issues.jboss.org/browse/ISPN-2280
Project: Infinispan
Issue Type: Feature Request
Components: Configuration, Loaders and Stores
Reporter: Galder Zamarreño
Assignee: Mircea Markus
Fix For: 5.2.0.Final
We should strive for correctness really.
Better to have someone complain about Infinispan not finishing rather than missing data in the cache store.
To avoid confusion, we should wait for a bit of time, i.e. 1 minute, and then if the async store has not finished yet, log a WARN message indicating what's up, but then carry on waiting forever (or whatever the defined user time - minus the 60 seconds) by default.
If the user defined timeout is less than 60 seconds, wait that long.
--
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, 1 month
[JBoss JIRA] (ISPN-2505) Java Activation Framework dependency unnessesary
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2505:
----------------------------------
Summary: Java Activation Framework dependency unnessesary
Key: ISPN-2505
URL: https://issues.jboss.org/browse/ISPN-2505
Project: Infinispan
Issue Type: Enhancement
Components: Build process
Affects Versions: 5.2.0.Beta3
Reporter: Thomas Fromm
Assignee: Mircea Markus
Priority: Optional
Distribution includes activation.jar. Since ISPN needs JDK6 jaf is already included in JDK and the with ISPN shipped version is anyway an old one.
--
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, 1 month
[JBoss JIRA] (ISPN-2504) WriteSkew check fails for entries which are inserted first time
by Radim Vansa (JIRA)
Radim Vansa created ISPN-2504:
---------------------------------
Summary: WriteSkew check fails for entries which are inserted first time
Key: ISPN-2504
URL: https://issues.jboss.org/browse/ISPN-2504
Project: Infinispan
Issue Type: Bug
Components: Locking and Concurrency
Affects Versions: 5.2.0.Beta3
Reporter: Radim Vansa
Assignee: Mircea Markus
If optimistic locking and write skew check are configured and there are two concurrent transactions performing
{code}
read(key) -> null
write(key, value)
{code}
one of them should fail (if both read {{null}}). However, both transaction succeed in this case. The reason is that that the {{VersionedPrepareCommand}} has {{null}} version for the key (because it was null) but in {{WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions}} there is
{code}
EntryVersion versionSeen = prepareCommand.getVersionsSeen().get(k);
if (versionSeen != null) entry.setVersion(versionSeen);
{code}
As the {{entry}} contains the version injected into context from {{dataContainer}} in {{EntryFactoryImpl.wrapInternalCacheEntryForPut}} lately during the {{VersionedPrepareCommand}} execution, and the version is not overwritten from the {{getVersionsSeen()}} value (as this is null), the performWriteSkewCheck does not report this entry as changed.
--
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, 1 month
[JBoss JIRA] (ISPN-2491) Order of locks in optimistic locking is not strict
by Radim Vansa (JIRA)
Radim Vansa created ISPN-2491:
---------------------------------
Summary: Order of locks in optimistic locking is not strict
Key: ISPN-2491
URL: https://issues.jboss.org/browse/ISPN-2491
Project: Infinispan
Issue Type: Quality Risk
Components: Locking and Concurrency
Affects Versions: 5.1.8.Final, 5.2.0.Beta3
Reporter: Radim Vansa
Assignee: Mircea Markus
Priority: Minor
In OptimisticLockingInterceptor, the keys are ordered according to their hash. However, the hashes can still collide, which may result in a deadlock if two keys with identical hash (only 32-bit) are sorted to different order. We should try to check if the keys are Comparable or let user provide some comparator class in config, and use the compare of hash only as the last resort.
In all cases, a warning should be emitted if the compare operation had non-strict result.
--
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, 1 month
[JBoss JIRA] (ISPN-2489) infinispan-core stores resources in default package, preventing OSGI export
by Vitalii Tymchyshyn (JIRA)
Vitalii Tymchyshyn created ISPN-2489:
----------------------------------------
Summary: infinispan-core stores resources in default package, preventing OSGI export
Key: ISPN-2489
URL: https://issues.jboss.org/browse/ISPN-2489
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.2.0.Beta3, 5.1.6.FINAL
Reporter: Vitalii Tymchyshyn
Assignee: Mircea Markus
Currently infinispan stores resources (e.g. infinispan-core-component-metadata.dat) in the default package. This makes this resources private to infinispan-core OSGI bundle as default package can't be exported
So, first of all it does not start by default when cache manager is created from another bundle. If configuration is created explicitly passing infinispan-core classloader, it can start, but no additional components can be used (e.g. loaders from another bundles).
I can see next possible options to handle this:
1) Move resources to the package
2) Use multiple classloaders to read resources (as it's done for classes)
3) Use exact classloader, e.g. use fixed infinispan-core classloader to get infinispan-core-component-metadata.dat. Dunno if this would work for all resources, like jgroups configuration files.
--
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, 1 month