[JBoss JIRA] (WFLY-6591) Memory leak of expired session in Infinispan cache with optimistic locking
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-6591?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance edited comment on WFLY-6591 at 5/5/16 12:05 PM:
-----------------------------------------------------------------
I'd like also to point out to a comment in the top of the class https://github.com/wildfly/wildfly/blob/master/clustering/web/infinispan/...:
{code}
/**
* Session expiration scheduler that eagerly expires sessions as soon as they are eligible.
* If/When Infinispan implements expiration notifications (ISPN-694), this will be obsolete.
* @author Paul Ferraro
*/
public class SessionExpirationScheduler implements Scheduler {
{code}
ISPN-694 has been resolved in Infinispan 8 which is now part of WF10.
Is there some remaining TODO's that were 'forgotten' ? Just in case...
was (Author: matlach):
I'd like also to pointout a comment in the top of the class https://github.com/wildfly/wildfly/blob/master/clustering/web/infinispan/...:
{code}
/**
* Session expiration scheduler that eagerly expires sessions as soon as they are eligible.
* If/When Infinispan implements expiration notifications (ISPN-694), this will be obsolete.
* @author Paul Ferraro
*/
public class SessionExpirationScheduler implements Scheduler {
{code}
ISPN-694 has been resolved in Infinispan 8 which is now part of WF10.
Is there some remaining TODO's that were 'forgotten' ? Just in case...
> Memory leak of expired session in Infinispan cache with optimistic locking
> --------------------------------------------------------------------------
>
> Key: WFLY-6591
> URL: https://issues.jboss.org/browse/WFLY-6591
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
>
> When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
> Session seems to be invalidated correctly and isn't accessible anymore.
> After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
> We've tried to adjust the code of org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() to the following:
> {code}
> private boolean remove(String id, Cache<SessionCreationMetaDataKey, SessionCreationMetaDataEntry<L>> creationMetaDataCache) {
> SessionCreationMetaDataKey key = new SessionCreationMetaDataKey(id);
> if (this.properties.isLockOnWrite()) {
> if (creationMetaDataCache.getAdvancedCache().withFlags(Flag.ZERO_LOCK_ACQUISITION_TIMEOUT, Flag.FAIL_SILENTLY).lock(key)) {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> return false;
> } else {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> }
> {code}
> With that change, the memory leaks disappears.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6591) Memory leak of expired session in Infinispan cache with optimistic locking
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-6591?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance edited comment on WFLY-6591 at 5/5/16 12:05 PM:
-----------------------------------------------------------------
I'd like also to point out a comment in the top of the class https://github.com/wildfly/wildfly/blob/master/clustering/web/infinispan/...:
{code}
/**
* Session expiration scheduler that eagerly expires sessions as soon as they are eligible.
* If/When Infinispan implements expiration notifications (ISPN-694), this will be obsolete.
* @author Paul Ferraro
*/
public class SessionExpirationScheduler implements Scheduler {
{code}
ISPN-694 has been resolved in Infinispan 8 which is now part of WF10.
Is there some remaining TODO's that were 'forgotten' ? Just in case...
was (Author: matlach):
I'd like also to point out to a comment in the top of the class https://github.com/wildfly/wildfly/blob/master/clustering/web/infinispan/...:
{code}
/**
* Session expiration scheduler that eagerly expires sessions as soon as they are eligible.
* If/When Infinispan implements expiration notifications (ISPN-694), this will be obsolete.
* @author Paul Ferraro
*/
public class SessionExpirationScheduler implements Scheduler {
{code}
ISPN-694 has been resolved in Infinispan 8 which is now part of WF10.
Is there some remaining TODO's that were 'forgotten' ? Just in case...
> Memory leak of expired session in Infinispan cache with optimistic locking
> --------------------------------------------------------------------------
>
> Key: WFLY-6591
> URL: https://issues.jboss.org/browse/WFLY-6591
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
>
> When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
> Session seems to be invalidated correctly and isn't accessible anymore.
> After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
> We've tried to adjust the code of org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() to the following:
> {code}
> private boolean remove(String id, Cache<SessionCreationMetaDataKey, SessionCreationMetaDataEntry<L>> creationMetaDataCache) {
> SessionCreationMetaDataKey key = new SessionCreationMetaDataKey(id);
> if (this.properties.isLockOnWrite()) {
> if (creationMetaDataCache.getAdvancedCache().withFlags(Flag.ZERO_LOCK_ACQUISITION_TIMEOUT, Flag.FAIL_SILENTLY).lock(key)) {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> return false;
> } else {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> }
> {code}
> With that change, the memory leaks disappears.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6591) Memory leak of expired session in Infinispan cache with optimistic locking
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-6591?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance commented on WFLY-6591:
----------------------------------------
I'd like also to pointout a comment in the top of the class https://github.com/wildfly/wildfly/blob/master/clustering/web/infinispan/...:
{code}
/**
* Session expiration scheduler that eagerly expires sessions as soon as they are eligible.
* If/When Infinispan implements expiration notifications (ISPN-694), this will be obsolete.
* @author Paul Ferraro
*/
public class SessionExpirationScheduler implements Scheduler {
{code}
ISPN-694 has been resolved in Infinispan 8 which is now part of WF10.
Is there some remaining TODO's that were 'forgotten' ? Just in case...
> Memory leak of expired session in Infinispan cache with optimistic locking
> --------------------------------------------------------------------------
>
> Key: WFLY-6591
> URL: https://issues.jboss.org/browse/WFLY-6591
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
>
> When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
> Session seems to be invalidated correctly and isn't accessible anymore.
> After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
> We've tried to adjust the code of org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() to the following:
> {code}
> private boolean remove(String id, Cache<SessionCreationMetaDataKey, SessionCreationMetaDataEntry<L>> creationMetaDataCache) {
> SessionCreationMetaDataKey key = new SessionCreationMetaDataKey(id);
> if (this.properties.isLockOnWrite()) {
> if (creationMetaDataCache.getAdvancedCache().withFlags(Flag.ZERO_LOCK_ACQUISITION_TIMEOUT, Flag.FAIL_SILENTLY).lock(key)) {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> return false;
> } else {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> }
> {code}
> With that change, the memory leaks disappears.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6591) Memory leak of expired session in Infinispan cache with optimistic locking
by Gabriel Lavoie (JIRA)
[ https://issues.jboss.org/browse/WFLY-6591?page=com.atlassian.jira.plugin.... ]
Gabriel Lavoie updated WFLY-6591:
---------------------------------
Description:
When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
Session seems to be invalidated correctly and isn't accessible anymore.
After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
We've tried to adjust the code of org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() to the following:
{code}
private boolean remove(String id, Cache<SessionCreationMetaDataKey, SessionCreationMetaDataEntry<L>> creationMetaDataCache) {
SessionCreationMetaDataKey key = new SessionCreationMetaDataKey(id);
if (this.properties.isLockOnWrite()) {
if (creationMetaDataCache.getAdvancedCache().withFlags(Flag.ZERO_LOCK_ACQUISITION_TIMEOUT, Flag.FAIL_SILENTLY).lock(key)) {
creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
return true;
}
return false;
} else {
creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
return true;
}
}
{code}
With that change, the memory leaks disappears.
was:
When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
Session seems to be invalidated correctly and isn't accessible anymore.
After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
> Memory leak of expired session in Infinispan cache with optimistic locking
> --------------------------------------------------------------------------
>
> Key: WFLY-6591
> URL: https://issues.jboss.org/browse/WFLY-6591
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
>
> When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
> Session seems to be invalidated correctly and isn't accessible anymore.
> After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
> We've tried to adjust the code of org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() to the following:
> {code}
> private boolean remove(String id, Cache<SessionCreationMetaDataKey, SessionCreationMetaDataEntry<L>> creationMetaDataCache) {
> SessionCreationMetaDataKey key = new SessionCreationMetaDataKey(id);
> if (this.properties.isLockOnWrite()) {
> if (creationMetaDataCache.getAdvancedCache().withFlags(Flag.ZERO_LOCK_ACQUISITION_TIMEOUT, Flag.FAIL_SILENTLY).lock(key)) {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> return false;
> } else {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> }
> {code}
> With that change, the memory leaks disappears.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6591) Memory leak of expired session in Infinispan cache with optimistic locking
by Gabriel Lavoie (JIRA)
Gabriel Lavoie created WFLY-6591:
------------------------------------
Summary: Memory leak of expired session in Infinispan cache with optimistic locking
Key: WFLY-6591
URL: https://issues.jboss.org/browse/WFLY-6591
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final, 10.1.0.Final
Reporter: Gabriel Lavoie
Assignee: Paul Ferraro
When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
Session seems to be invalidated correctly and isn't accessible anymore.
After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by George Turner (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
George Turner resolved WFLY-4769.
---------------------------------
Resolution: Done
Thank you VERY MUCH for providing a valid response! This worked entirely as expected!
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (DROOLS-1166) ClassNotFoundException for the drools function when large number of valuations
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1166?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1166:
-------------------------------------
Using the lambda inside the function works because it uses the java.lang.invoke.LambdaMetafactory instead of looking for the inner class.
This is really a extreme edge case and I'm not sure if we want to support this, but I'll keep investigating a bit more.
> ClassNotFoundException for the drools function when large number of valuations
> ------------------------------------------------------------------------------
>
> Key: DROOLS-1166
> URL: https://issues.jboss.org/browse/DROOLS-1166
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: 20160505.testjitfunction.zip
>
>
> Hello, for a large number of evaluations a {{ClassNotFoundException}} is thrown missing to find appropriate class for the drools function defined.
> In the attached reproducer, a for loop inserts a given number of facts into the session; for a small number of facts, no error is thrown.
> For example given
> {code}
> for (int i=0; i<20; i++) {
> session.insert("Ciao "+i);
> session.fireAllRules();
> }
> {code}
> all is fine.
> When running with say:
> {code}
> for (int i=0; i<150; i++) {
> session.insert("Ciao "+i);
> session.fireAllRules();
> }
> {code}
> then throws, snippet:
> {code}
> java.lang.NoClassDefFoundError: com/acme/testjitfunction/EntryKey$1
> at com.acme.testjitfunction.EntryKey.entryKey(EntryKey.java:51)
> at ConditionEvaluator1fae754676b54e869aa5b558ba2d7991.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.phreak.PhreakAccumulateNode.evaluateResultConstraints(PhreakAccumulateNode.java:696)
> at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:114)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:534)
> [...]
> Caused by: java.lang.ClassNotFoundException: com.acme.testjitfunction.EntryKey$1
> at java.lang.ClassLoader.findClass(ClassLoader.java:530)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at org.drools.core.common.ProjectClassLoader$DefaultInternalTypesClassLoader.loadType(ProjectClassLoader.java:393)
> at org.drools.core.common.ProjectClassLoader$DefaultInternalTypesClassLoader.loadClass(ProjectClassLoader.java:380)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 44 more
> {code}
> I'm also wondering if maybe this is not the best possible way to "backport" lambdas as a drool function; in case a more proper way to implement them as a drool function is possible, kindly let me know.
> Can you kindly advise, please?
> Thank you very much
> Ciao
> MM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (DROOLS-1166) ClassNotFoundException for the drools function when large number of valuations
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1166?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1166:
-------------------------------------
Your test cases is a bit convoluted and I'm not sure why you're attempting this. It seems that you found a ClassLoader problem caused by the anonymous inner class defined in your function. I'm trying to figure out what's happening there. Also consider that if you replace
{code}
function Function<Entry, Object> entryKey() {
return new Function<Entry, Object>() {
@Override
public Object apply(Entry e) {
return e.getKey();
}
};
}
{code}
with
{code}
function Function<Entry, Object> entryKey() {
return (Entry e) -> e.getKey();
}
{code}
it works as expected ... even if at the moment I'm not sure why :)
> ClassNotFoundException for the drools function when large number of valuations
> ------------------------------------------------------------------------------
>
> Key: DROOLS-1166
> URL: https://issues.jboss.org/browse/DROOLS-1166
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: 20160505.testjitfunction.zip
>
>
> Hello, for a large number of evaluations a {{ClassNotFoundException}} is thrown missing to find appropriate class for the drools function defined.
> In the attached reproducer, a for loop inserts a given number of facts into the session; for a small number of facts, no error is thrown.
> For example given
> {code}
> for (int i=0; i<20; i++) {
> session.insert("Ciao "+i);
> session.fireAllRules();
> }
> {code}
> all is fine.
> When running with say:
> {code}
> for (int i=0; i<150; i++) {
> session.insert("Ciao "+i);
> session.fireAllRules();
> }
> {code}
> then throws, snippet:
> {code}
> java.lang.NoClassDefFoundError: com/acme/testjitfunction/EntryKey$1
> at com.acme.testjitfunction.EntryKey.entryKey(EntryKey.java:51)
> at ConditionEvaluator1fae754676b54e869aa5b558ba2d7991.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.phreak.PhreakAccumulateNode.evaluateResultConstraints(PhreakAccumulateNode.java:696)
> at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:114)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:534)
> [...]
> Caused by: java.lang.ClassNotFoundException: com.acme.testjitfunction.EntryKey$1
> at java.lang.ClassLoader.findClass(ClassLoader.java:530)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at org.drools.core.common.ProjectClassLoader$DefaultInternalTypesClassLoader.loadType(ProjectClassLoader.java:393)
> at org.drools.core.common.ProjectClassLoader$DefaultInternalTypesClassLoader.loadClass(ProjectClassLoader.java:380)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 44 more
> {code}
> I'm also wondering if maybe this is not the best possible way to "backport" lambdas as a drool function; in case a more proper way to implement them as a drool function is possible, kindly let me know.
> Can you kindly advise, please?
> Thank you very much
> Ciao
> MM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months