[JBoss JIRA] (ISPN-5631) NearCache: ability di wait for other Java HotRod clients to invalidate lazy near cache on remove
by Enrico Olivelli (JIRA)
[ https://issues.jboss.org/browse/ISPN-5631?page=com.atlassian.jira.plugin.... ]
Enrico Olivelli commented on ISPN-5631:
---------------------------------------
Maybe it could be a flag:
Cache<String, String> cache = ...;
cache.getAdvancedCache().withFlags(Flag.WAIT_REMOTE_NEAR_CACHES_INVALIDATION)
.put("last-login-date", "2012.08.31");
A timeout should be configurable for this kind of operations on the nearcache client side config.
Even if it would be expensive for the server I think that this feature will be very useful because with such an ability the hotrod client + nearcache can be used in simple transactions with Last Resource Optimization technique: the client would perform a commit on sql database (or other transactional resource, such as JMS queue) and then invalidate the cache.
In fact we use such a tecnique for SQL databases and ActiveMQ queues, and using Infinispan as cache provider sometimes it appens that another (remote) thread which reads data from the nearcache after receiving a JMS message it get a stale value
Another useful flag (maybe it would be better to file JIRA issue) is would be a flag to skip the NearCache for "important gets", that is for "get operations" that you want to be in synch with the "real data" stored on the cache servers.
> NearCache: ability di wait for other Java HotRod clients to invalidate lazy near cache on remove
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-5631
> URL: https://issues.jboss.org/browse/ISPN-5631
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 7.2.3.Final
> Environment: Java hotrod client/server
> Reporter: Enrico Olivelli
> Labels: hotrod-java-client
>
> When a Java HotRod client invalidates (remove) an entry it is possibile that this action is not propagated with enough speed to other clients due to the async nature of event notifcations used by NearCache, an so it is possibile that another client looks up a stale entry from its near cache.
> A typical "writer client" scenario is:
> - update the database and commit the transaction
> - invalidate the entry which represents the updated (only a "remove")
> The "reader" procedure is:
> - lookup in the cache (nearcache, backed by the remote Infinispan cluster)
> - in case of "cache miss" perform a lookup on the database and write the entry in the cache
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5705) Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5705?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-5705:
-------------------------------------
Thanks! I've added a fix and test for this in the linked pull request. This should make it into master today.
> Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-5705
> URL: https://issues.jboss.org/browse/ISPN-5705
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta3
> Environment: Hibrid Query that includes 'OR' condition fails in certain specific cases
> Reporter: Prashanth Reddy
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 8.0.0.Final
>
> Attachments: BooleShannonExpansion.diff
>
>
> The hibrid query, mentioned below produces wrong results, upon execution.
> SELECT p.ID, p.NAME FROM com.testapp.Person p WHERE p.IS_ACTIVE=1 AND (p.CITY='city1' OR p.CITY='city2') AND p.ID>1000
> for the Data:
> ID | NAME | CITY | IS_ACTIVE
> -------------------
> 2001 person1 city1 1
> 2002 person1 city1 1
> 2003 person1 city1 1
> 2004 person1 city1 0
> 2005 person1 city2 1
> 2006 person1 city2 1
> 2007 person1 city3 0
> 2008 person1 city3 1
> Indexed fields: ID, NAME, CITY
> Non-indexed fields: IS_ACTIVE
> Query execution returned 0 number of rows, whereas expected result count is 5.
> After some analysis root cause for the problem has been found, and the details are as follows,
> As a part of separating the query that depends on indexed fields, using boole shannon algorithm, it has first extraced out the condition 'IS_ACTIVE=1' (as it deals with non-indexed fields).
> Assuming four boolean conditions as c1, c2, c3, c4, where c1 represents the condition 'IS_ACTIVE=1'
> f(c1,c2,c3,c4) = c1.f(1, c2, c3, c4) + c1`.f`(0, c2, c3, c4)
> consider
> e1=f(1, c2, c3, c4)
> e2=f`(0, c2, c3, c4)
> which have to be used for constructing the lucene query, for further transformation.
> After splitting as per the above logic, it is trying to optimize the resultant subconditions(e1, e2), so as to reduce the number of conditions to be evaluated. One such optimization that has been found is that when there is a conjuction operation between two comparison predicates dealing with same lvalues(here, same fields), but with the different rvalues(here, constants), it has been optimized to replace it with a contradiction(constant false boolean expression). As we know, this optimization is applicable only for conjuction. But, the same is applied even for the disjuction, which is causing the above mentioned problem.
> For example,
> condition p.CITY='city1' AND p.CITY='city2'
> can be replaced with CONTRADICTION(BooleanConst.FALSE)
> But, the same cannot be done, for
> condition p.CITY='city1' OR p.CITY='city2'
> Following change may correct the problem.
> File: infinispan-8.0.0.Beta3/object-filter/src/main/java/org/infinispan/objectfilter/impl/syntax/BooleShannonExpansion.java:155
> diff:
> @@ -152,7 +152,7 @@
> }
> }
> }
> - PredicateOptimisations.optimizePredicates(newChildren, true);
> + PredicateOptimisations.optimizePredicates(newChildren, false);
> if (newChildren.size() == 1) {
> return newChildren.get(0);
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5706) Execution of a Hibrid Query returns incorrect results, when the filter condition fails(match() returns false) for at least some of the results returned by the lucene query execution, before reaching any other successful results(which satisfies the filter)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5706?page=com.atlassian.jira.plugin.... ]
Adrian Nistor closed ISPN-5706.
-------------------------------
Resolution: Done
Fixed in commit f01512f9eb3088a01c4583e1470738c16a596c18 on master branch.
> Execution of a Hibrid Query returns incorrect results, when the filter condition fails(match() returns false) for at least some of the results returned by the lucene query execution, before reaching any other successful results(which satisfies the filter)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5706
> URL: https://issues.jboss.org/browse/ISPN-5706
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta3
> Reporter: Prashanth Reddy
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 8.0.0.Final
>
> Attachments: HybridQuery.diff
>
>
> The hibrid query, mentioned below produces partial or zero results(depending on the data), upon execution.
> SELECT p.ID, p.NAME FROM com.testapp.Person p WHERE p.IS_ACTIVE=1 AND p.ID>1000 and p.ID<10000
> For the data,
> ID | NAME | CITY | IS_ACTIVE
> -------------------
> 2001 person1 city1 0
> 2002 person1 city1 1
> 2003 person1 city1 1
> 2004 person1 city1 0
> 2005 person1 city2 1
> 2006 person1 city2 1
> 2007 person1 city3 0
> 2008 person1 city3 1
> Indexed fields: ID, NAME, CITY
> Non-indexed fields: IS_ACTIVE
> Query execution returned 0 number of rows, whereas expected result count is 8.
> Root cause for the problem is very trivial, and the details are as follows,
> As we know, hibrid query execution involves,
> * Execution of lucene query that is constructed based on boole shannon expansion
> * Applying filter on the results obtained from above operation, in order to cover the conditions that deals with non-indexed fields
> In the second step, there is a mismatch between the representation of filter operation return status and the way end of the result list is detected at the outer layer.
> As per the current implementation, filter operation returns null, if the filter condition is not satisfied. But, the same is also used for determining whether there are any further results to be retrieved, which is causing the actual problem.
> Following changes can resolve the problem,
> file: infinispan-8.0.0.Beta3/query/src/main/java/org/infinispan/query/dsl/embedded/impl/HybridQuery.java
> diff:
> Index: infinispan-8.0.0.Beta3/query/src/main/java/org/infinispan/query/dsl/embedded/impl/HybridQuery.java
> ===================================================================
> --- infinispan-8.0.0.Beta3/query/src/main/java/org/infinispan/query/dsl/embedded/impl/HybridQuery.java (revision -----)
> +++ infinispan-8.0.0.Beta3/query/src/main/java/org/infinispan/query/dsl/embedded/impl/HybridQuery.java (working copy)
> @@ -70,12 +70,15 @@
>
> private void update() {
> if (!isReady) {
> - if (it.hasNext()) {
> - Object next = it.next();
> - nextResult = objectFilter.filter(next);
> - } else {
> - nextResult = null;
> - }
> + do {
> + if (it.hasNext()) {
> + Object next = it.next();
> + nextResult = objectFilter.filter(next);
> + } else {
> + nextResult = null;
> + break;
> + }
> + } while (nextResult == null);
> isReady = true;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5706) Execution of a Hibrid Query returns incorrect results, when the filter condition fails(match() returns false) for at least some of the results returned by the lucene query execution, before reaching any other successful results(which satisfies the filter)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5706?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-5706:
-------------------------------------
Hi Prashanth,
I started investigating this and then I found out I just fixed this exact issue incidentally while fixing ISPN-5685, see commit f01512f9eb3088a01c4583e1470738c16a596c18 on master branch.
Thank you for reporting this.
> Execution of a Hibrid Query returns incorrect results, when the filter condition fails(match() returns false) for at least some of the results returned by the lucene query execution, before reaching any other successful results(which satisfies the filter)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5706
> URL: https://issues.jboss.org/browse/ISPN-5706
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta3
> Reporter: Prashanth Reddy
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 8.0.0.Final
>
> Attachments: HybridQuery.diff
>
>
> The hibrid query, mentioned below produces partial or zero results(depending on the data), upon execution.
> SELECT p.ID, p.NAME FROM com.testapp.Person p WHERE p.IS_ACTIVE=1 AND p.ID>1000 and p.ID<10000
> For the data,
> ID | NAME | CITY | IS_ACTIVE
> -------------------
> 2001 person1 city1 0
> 2002 person1 city1 1
> 2003 person1 city1 1
> 2004 person1 city1 0
> 2005 person1 city2 1
> 2006 person1 city2 1
> 2007 person1 city3 0
> 2008 person1 city3 1
> Indexed fields: ID, NAME, CITY
> Non-indexed fields: IS_ACTIVE
> Query execution returned 0 number of rows, whereas expected result count is 8.
> Root cause for the problem is very trivial, and the details are as follows,
> As we know, hibrid query execution involves,
> * Execution of lucene query that is constructed based on boole shannon expansion
> * Applying filter on the results obtained from above operation, in order to cover the conditions that deals with non-indexed fields
> In the second step, there is a mismatch between the representation of filter operation return status and the way end of the result list is detected at the outer layer.
> As per the current implementation, filter operation returns null, if the filter condition is not satisfied. But, the same is also used for determining whether there are any further results to be retrieved, which is causing the actual problem.
> Following changes can resolve the problem,
> file: infinispan-8.0.0.Beta3/query/src/main/java/org/infinispan/query/dsl/embedded/impl/HybridQuery.java
> diff:
> Index: infinispan-8.0.0.Beta3/query/src/main/java/org/infinispan/query/dsl/embedded/impl/HybridQuery.java
> ===================================================================
> --- infinispan-8.0.0.Beta3/query/src/main/java/org/infinispan/query/dsl/embedded/impl/HybridQuery.java (revision -----)
> +++ infinispan-8.0.0.Beta3/query/src/main/java/org/infinispan/query/dsl/embedded/impl/HybridQuery.java (working copy)
> @@ -70,12 +70,15 @@
>
> private void update() {
> if (!isReady) {
> - if (it.hasNext()) {
> - Object next = it.next();
> - nextResult = objectFilter.filter(next);
> - } else {
> - nextResult = null;
> - }
> + do {
> + if (it.hasNext()) {
> + Object next = it.next();
> + nextResult = objectFilter.filter(next);
> + } else {
> + nextResult = null;
> + break;
> + }
> + } while (nextResult == null);
> isReady = true;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5705) Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5705?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5705:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3629
> Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-5705
> URL: https://issues.jboss.org/browse/ISPN-5705
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta3
> Environment: Hibrid Query that includes 'OR' condition fails in certain specific cases
> Reporter: Prashanth Reddy
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 8.0.0.Final
>
> Attachments: BooleShannonExpansion.diff
>
>
> The hibrid query, mentioned below produces wrong results, upon execution.
> SELECT p.ID, p.NAME FROM com.testapp.Person p WHERE p.IS_ACTIVE=1 AND (p.CITY='city1' OR p.CITY='city2') AND p.ID>1000
> for the Data:
> ID | NAME | CITY | IS_ACTIVE
> -------------------
> 2001 person1 city1 1
> 2002 person1 city1 1
> 2003 person1 city1 1
> 2004 person1 city1 0
> 2005 person1 city2 1
> 2006 person1 city2 1
> 2007 person1 city3 0
> 2008 person1 city3 1
> Indexed fields: ID, NAME, CITY
> Non-indexed fields: IS_ACTIVE
> Query execution returned 0 number of rows, whereas expected result count is 5.
> After some analysis root cause for the problem has been found, and the details are as follows,
> As a part of separating the query that depends on indexed fields, using boole shannon algorithm, it has first extraced out the condition 'IS_ACTIVE=1' (as it deals with non-indexed fields).
> Assuming four boolean conditions as c1, c2, c3, c4, where c1 represents the condition 'IS_ACTIVE=1'
> f(c1,c2,c3,c4) = c1.f(1, c2, c3, c4) + c1`.f`(0, c2, c3, c4)
> consider
> e1=f(1, c2, c3, c4)
> e2=f`(0, c2, c3, c4)
> which have to be used for constructing the lucene query, for further transformation.
> After splitting as per the above logic, it is trying to optimize the resultant subconditions(e1, e2), so as to reduce the number of conditions to be evaluated. One such optimization that has been found is that when there is a conjuction operation between two comparison predicates dealing with same lvalues(here, same fields), but with the different rvalues(here, constants), it has been optimized to replace it with a contradiction(constant false boolean expression). As we know, this optimization is applicable only for conjuction. But, the same is applied even for the disjuction, which is causing the above mentioned problem.
> For example,
> condition p.CITY='city1' AND p.CITY='city2'
> can be replaced with CONTRADICTION(BooleanConst.FALSE)
> But, the same cannot be done, for
> condition p.CITY='city1' OR p.CITY='city2'
> Following change may correct the problem.
> File: infinispan-8.0.0.Beta3/object-filter/src/main/java/org/infinispan/objectfilter/impl/syntax/BooleShannonExpansion.java:155
> diff:
> @@ -152,7 +152,7 @@
> }
> }
> }
> - PredicateOptimisations.optimizePredicates(newChildren, true);
> + PredicateOptimisations.optimizePredicates(newChildren, false);
> if (newChildren.size() == 1) {
> return newChildren.get(0);
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5705) Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5705?page=com.atlassian.jira.plugin.... ]
Work on ISPN-5705 started by Adrian Nistor.
-------------------------------------------
> Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-5705
> URL: https://issues.jboss.org/browse/ISPN-5705
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta3
> Environment: Hibrid Query that includes 'OR' condition fails in certain specific cases
> Reporter: Prashanth Reddy
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 8.0.0.Final
>
> Attachments: BooleShannonExpansion.diff
>
>
> The hibrid query, mentioned below produces wrong results, upon execution.
> SELECT p.ID, p.NAME FROM com.testapp.Person p WHERE p.IS_ACTIVE=1 AND (p.CITY='city1' OR p.CITY='city2') AND p.ID>1000
> for the Data:
> ID | NAME | CITY | IS_ACTIVE
> -------------------
> 2001 person1 city1 1
> 2002 person1 city1 1
> 2003 person1 city1 1
> 2004 person1 city1 0
> 2005 person1 city2 1
> 2006 person1 city2 1
> 2007 person1 city3 0
> 2008 person1 city3 1
> Indexed fields: ID, NAME, CITY
> Non-indexed fields: IS_ACTIVE
> Query execution returned 0 number of rows, whereas expected result count is 5.
> After some analysis root cause for the problem has been found, and the details are as follows,
> As a part of separating the query that depends on indexed fields, using boole shannon algorithm, it has first extraced out the condition 'IS_ACTIVE=1' (as it deals with non-indexed fields).
> Assuming four boolean conditions as c1, c2, c3, c4, where c1 represents the condition 'IS_ACTIVE=1'
> f(c1,c2,c3,c4) = c1.f(1, c2, c3, c4) + c1`.f`(0, c2, c3, c4)
> consider
> e1=f(1, c2, c3, c4)
> e2=f`(0, c2, c3, c4)
> which have to be used for constructing the lucene query, for further transformation.
> After splitting as per the above logic, it is trying to optimize the resultant subconditions(e1, e2), so as to reduce the number of conditions to be evaluated. One such optimization that has been found is that when there is a conjuction operation between two comparison predicates dealing with same lvalues(here, same fields), but with the different rvalues(here, constants), it has been optimized to replace it with a contradiction(constant false boolean expression). As we know, this optimization is applicable only for conjuction. But, the same is applied even for the disjuction, which is causing the above mentioned problem.
> For example,
> condition p.CITY='city1' AND p.CITY='city2'
> can be replaced with CONTRADICTION(BooleanConst.FALSE)
> But, the same cannot be done, for
> condition p.CITY='city1' OR p.CITY='city2'
> Following change may correct the problem.
> File: infinispan-8.0.0.Beta3/object-filter/src/main/java/org/infinispan/objectfilter/impl/syntax/BooleShannonExpansion.java:155
> diff:
> @@ -152,7 +152,7 @@
> }
> }
> }
> - PredicateOptimisations.optimizePredicates(newChildren, true);
> + PredicateOptimisations.optimizePredicates(newChildren, false);
> if (newChildren.size() == 1) {
> return newChildren.get(0);
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5705) Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5705?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5705:
--------------------------------
Fix Version/s: 8.0.0.Final
> Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-5705
> URL: https://issues.jboss.org/browse/ISPN-5705
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta3
> Environment: Hibrid Query that includes 'OR' condition fails in certain specific cases
> Reporter: Prashanth Reddy
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 8.0.0.Final
>
> Attachments: BooleShannonExpansion.diff
>
>
> The hibrid query, mentioned below produces wrong results, upon execution.
> SELECT p.ID, p.NAME FROM com.testapp.Person p WHERE p.IS_ACTIVE=1 AND (p.CITY='city1' OR p.CITY='city2') AND p.ID>1000
> for the Data:
> ID | NAME | CITY | IS_ACTIVE
> -------------------
> 2001 person1 city1 1
> 2002 person1 city1 1
> 2003 person1 city1 1
> 2004 person1 city1 0
> 2005 person1 city2 1
> 2006 person1 city2 1
> 2007 person1 city3 0
> 2008 person1 city3 1
> Indexed fields: ID, NAME, CITY
> Non-indexed fields: IS_ACTIVE
> Query execution returned 0 number of rows, whereas expected result count is 5.
> After some analysis root cause for the problem has been found, and the details are as follows,
> As a part of separating the query that depends on indexed fields, using boole shannon algorithm, it has first extraced out the condition 'IS_ACTIVE=1' (as it deals with non-indexed fields).
> Assuming four boolean conditions as c1, c2, c3, c4, where c1 represents the condition 'IS_ACTIVE=1'
> f(c1,c2,c3,c4) = c1.f(1, c2, c3, c4) + c1`.f`(0, c2, c3, c4)
> consider
> e1=f(1, c2, c3, c4)
> e2=f`(0, c2, c3, c4)
> which have to be used for constructing the lucene query, for further transformation.
> After splitting as per the above logic, it is trying to optimize the resultant subconditions(e1, e2), so as to reduce the number of conditions to be evaluated. One such optimization that has been found is that when there is a conjuction operation between two comparison predicates dealing with same lvalues(here, same fields), but with the different rvalues(here, constants), it has been optimized to replace it with a contradiction(constant false boolean expression). As we know, this optimization is applicable only for conjuction. But, the same is applied even for the disjuction, which is causing the above mentioned problem.
> For example,
> condition p.CITY='city1' AND p.CITY='city2'
> can be replaced with CONTRADICTION(BooleanConst.FALSE)
> But, the same cannot be done, for
> condition p.CITY='city1' OR p.CITY='city2'
> Following change may correct the problem.
> File: infinispan-8.0.0.Beta3/object-filter/src/main/java/org/infinispan/objectfilter/impl/syntax/BooleShannonExpansion.java:155
> diff:
> @@ -152,7 +152,7 @@
> }
> }
> }
> - PredicateOptimisations.optimizePredicates(newChildren, true);
> + PredicateOptimisations.optimizePredicates(newChildren, false);
> if (newChildren.size() == 1) {
> return newChildren.get(0);
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5711) Component injection should deal with optional "provided" dependencies (i.e. javax.transaction)
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-5711:
-------------------------------------
Summary: Component injection should deal with optional "provided" dependencies (i.e. javax.transaction)
Key: ISPN-5711
URL: https://issues.jboss.org/browse/ISPN-5711
Project: Infinispan
Issue Type: Bug
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
On initialization of the GlobalComponentRegistry, component injection attempts to resolve all classes for all methods in the declaration chain of all the components which might require injection.
If we ever want to make some dependency truly optional (and "provided" at the maven dep level), we would need to ignore certain classes and inject nulls where necessary.
Exception in thread "main" org.infinispan.commons.CacheException: Unable to construct a GlobalComponentRegistry!
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:136)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:214)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:134)
at org.infinispan.tutorial.simple.map.InfinispanMap.main(InfinispanMap.java:10)
Caused by: org.infinispan.commons.CacheException: Error injecting dependencies for component org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifier
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:197)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:148)
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:114)
... 3 more
Caused by: java.lang.NoClassDefFoundError: javax/transaction/Transaction
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.getDeclaredMethod(Class.java:2128)
at org.infinispan.commons.util.ReflectionUtil.findMethod(ReflectionUtil.java:98)
at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:826)
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:195)
... 6 more
Caused by: java.lang.ClassNotFoundException: javax.transaction.Transaction
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 12 more
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5696) javax.transaction dependency should be compile
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5696?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5696:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3679
> javax.transaction dependency should be compile
> ----------------------------------------------
>
> Key: ISPN-5696
> URL: https://issues.jboss.org/browse/ISPN-5696
> Project: Infinispan
> Issue Type: Feature Request
> Components: Build process
> Affects Versions: 8.0.0.CR1
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> ISPN-5541 made all javax dependencies provided, including javax.transaction. This dependency though is needed for building transactional configuration, even if you're using no transactional configurations. E.g. constructing {{new DefaultCacheManager()}} without that dependency throws:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at org.infinispan.configuration.cache.TransactionConfiguration.<clinit>(TransactionConfiguration.java:30)
> at org.infinispan.configuration.cache.TransactionConfigurationBuilder.<init>(TransactionConfigurationBuilder.java:37)
> at org.infinispan.configuration.cache.ConfigurationBuilder.<init>(ConfigurationBuilder.java:53)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:213)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:134)
> at org.infinispan.tutorial.simple.functional.InfinispanFunctional.main(InfinispanFunctional.java:22)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Caused by: java.lang.ClassNotFoundException: javax.transaction.TransactionManager
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 11 more
> {code}
> The quick fix is to reinstate not-provided for {{javax.transaction}}. Longer term, this dependency should not kick in unless you have a transactional cache configuration.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5696) javax.transaction dependency should be compile
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5696?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-5696:
-------------------------------------
Assignee: Tristan Tarrant (was: Galder Zamarreño)
> javax.transaction dependency should be compile
> ----------------------------------------------
>
> Key: ISPN-5696
> URL: https://issues.jboss.org/browse/ISPN-5696
> Project: Infinispan
> Issue Type: Feature Request
> Components: Build process
> Affects Versions: 8.0.0.CR1
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> ISPN-5541 made all javax dependencies provided, including javax.transaction. This dependency though is needed for building transactional configuration, even if you're using no transactional configurations. E.g. constructing {{new DefaultCacheManager()}} without that dependency throws:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at org.infinispan.configuration.cache.TransactionConfiguration.<clinit>(TransactionConfiguration.java:30)
> at org.infinispan.configuration.cache.TransactionConfigurationBuilder.<init>(TransactionConfigurationBuilder.java:37)
> at org.infinispan.configuration.cache.ConfigurationBuilder.<init>(ConfigurationBuilder.java:53)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:213)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:134)
> at org.infinispan.tutorial.simple.functional.InfinispanFunctional.main(InfinispanFunctional.java:22)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Caused by: java.lang.ClassNotFoundException: javax.transaction.TransactionManager
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 11 more
> {code}
> The quick fix is to reinstate not-provided for {{javax.transaction}}. Longer term, this dependency should not kick in unless you have a transactional cache configuration.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months