[JBoss JIRA] (JGRP-2040) Seeing a OOM in JGroup 3.4
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2040?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2040:
--------------------------------
Apparently, the receiver is reading an int which should be the length of the following buffer, but the data it is reading doesn't have an int. Is some other process sending data to the JGroups process? This could lead to TCP interpreting random data as an int (which is way to large).
> Seeing a OOM in JGroup 3.4
> --------------------------
>
> Key: JGRP-2040
> URL: https://issues.jboss.org/browse/JGRP-2040
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Environment: Linux Operating System
> Reporter: Kshitiz Saxena
> Assignee: Bela Ban
>
> We are seeing an OOM in our application where thread dump points to JGroup.
> We see the below in thread dumps,
> 3XEHSTTYPE 07:33:24:346241000 GMT j9vm.294 - >setCurrentException index=11 constructorIndex=0 detailMessage=0000000000F61678
> 3XEHSTTYPE 07:33:24:346183000 GMT j9mm.126 - at 0000000050F8CD60 java/lang/Thread.run()V, jit 00007FCF323EA580, pc 00007FCF489E0A36
> 3XEHSTTYPE 07:33:24:346179000 GMT j9mm.126 - at 0000000053644748 *org/jgroups/blocks/TCPConnectionMap$TCPConnection$Receiver.run()*V, jit 0000000000000000, pc 00007FCF3354D334
> 3XEHSTTYPE 07:33:24:346175000 GMT j9mm.101 - J9AllocateIndexableObject() returning NULL! *1650814064 bytes* requested for object of class 0000000050F79700 from memory space 'Generational' id=00007FCF440427C0
> In the thread dump we also see
> WARNING : OutOfMemoryError possibly caused by 1650814064 bytes requested for object of class 0000000050F79700 from memory space 'Generational' id=00007FCF440427C0
> Java Heap Information
> -Xmx (Maximum Java heap size) : 1280m
> -Xms (Initial Java heap size) : 640m
> -Xss (Maximum stack size for Java threads) : 256k
> Total Java heap size: 1.25 GB
> Used Java heap size: 174.27 MB
> Free Java heap size: 1.08 GB
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.
by Gabriel Lavoie (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Gabriel Lavoie edited comment on WFLY-6489 at 4/6/16 9:22 AM:
--------------------------------------------------------------
Hi Paul,
At this time our app has business transactions that access the session in a single thread of the JVM that may take longer than 15 seconds (realizing this is configurable, but the problem remains the same just with longer waits) resulting in blocking and eventual timeout of other business transactions happening concurrently with that session.
We rely heavily on the developer being responsible for the providing thread safe access to the attributes in the session. Setting the container to pessimistic (even if we can improve/stabilize concurrent access cases in the app) provides a very large lock on our apps concurrency and will appear like a performance hit. SRV.7.7.1 (servlet-3.1 https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf) allows such concurrent access on the session with a synchronization on the session and not on the request.
SRV.7.7.2 also mentions that all request that are part of a session should hit the same JVM (we use sticky session) and that the developer should expect no additional concurrency issues beyond those encountered in a non-distributed container. The issue described here occurs while hitting only a single JVM with <distributable /> sessions.
I'm attaching an updated sample webapp that can reproduce the issue with every session creation (/issue/sessionissuedisplayservlet), not just the first time after startup. In that sample, we think that the JSESSIONID should never be returned to the browser with the session not accessible on a separate request on the same node.
After digging a bit in the WildFly code, we found a possible workaround to force the commit/replication of a new session by calling updateSessionAccessTime(), but it has the side effect of blocking the replication of any session attribute updated after this forced replication until the session is modified by a future request. Note that sendRedirect() has this same bad side effects if any session attribute is updated after the call as it also immediately updates the session access time.
Regards
was (Author: glavoie):
Hi Paul,
At this time our app has business transactions that access the session in a single thread of the JVM that may take longer than 15 seconds (realizing this is configurable, but the problem remains the same just with longer waits) resulting in blocking and eventual timeout of other business transactions happening concurrently with that session.
We rely heavily on the developer being responsible for the providing thread safe access to the attributes in the session. Setting the container to pessimistic (even if we can improve/stabilize concurrent access cases in the app) provides a very large lock on our apps concurrency and will appear like a performance hit. SRV.7.7.1 (servlet-3.1 https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf) allows such concurrent access on the session with a synchronization on the session and not on the request.
SRV.7.7.2 also mentions that all request that are part of a session should hit the same JVM (we use sticky session) and that the developer should expect no additional concurrency issues beyond those encountered in a non-distributed container. The issue described here occurs only while hitting a single JVM with <distributable /> sessions.
I'm attaching an updated sample webapp that can reproduce the issue with every session creation (/issue/sessionissuedisplayservlet), not just the first time after startup. In that sample, we think that the JSESSIONID should never be returned to the browser with the session not accessible on a separate request on the same node.
After digging a bit in the WildFly code, we found a possible workaround to force the commit/replication of a new session by calling updateSessionAccessTime(), but it has the side effect of blocking the replication of any session attribute updated after this forced replication until the session is modified by a future request. Note that sendRedirect() has this same bad side effects if any session attribute is updated after the call as it also immediately updates the session access time.
Regards
> Distributable session may not exist after redirect to same node with optimistic locking.
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6489
> URL: https://issues.jboss.org/browse/WFLY-6489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final, 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: wfly-6489-showcase.zip, wildfly-10-session-issue.zip
>
>
> I'm currently working on porting an application running on EAP 6.1 to WildFly 10 and am encountering multiple session/authentication issues with clustering enabled. Our login flow currently starts from a servlet that accepts the credentials, creates the session, then redirect to the welcome page.
> The first time we execute this flow after the startup of a node, the welcome page can't see at all the session created previously.
> - request.getSession() creates yet another session and a new session cookie is returned.
> - request.getSession(false) returns "null"
> On the second attempt, the flow works as expected.
> The issue can be reproduced on both a single node or a two nodes cluster, as long as <distributable /> is enabled in web.xml.
> We are currently using the master build https://ci.jboss.org/hudson/job/WildFly-latest-master/2244/, but the problem has been noticed on 10.0.0-Final and also 8.2.1-Final.
> I attached a sample web application that I used to reproduce the issue. Our standalone.xml is also included with the clustering configuration we've been using for the web/session cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.
by Gabriel Lavoie (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Gabriel Lavoie commented on WFLY-6489:
--------------------------------------
Hi Paul,
At this time our app has business transactions that access the session in a single thread of the JVM that may take longer than 15 seconds (realizing this is configurable, but the problem remains the same just with longer waits) resulting in blocking and eventual timeout of other business transactions happening concurrently with that session.
We rely heavily on the developer being responsible for the providing thread safe access to the attributes in the session. Setting the container to pessimistic (even if we can improve/stabilize concurrent access cases in the app) provides a very large lock on our apps concurrency and will appear like a performance hit. SRV.7.7.1 (servlet-3.1 https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf) allows such concurrent access on the session with a synchronization on the session and not on the request.
SRV.7.7.2 also mentions that all request that are part of a session should hit the same JVM (we use sticky session) and that the developer should expect no additional concurrency issues beyond those encountered in a non-distributed container. The issue described here occurs only while hitting a single JVM with <distributable /> sessions.
I'm attaching an updated sample webapp that can reproduce the issue with every session creation (/issue/sessionissuedisplayservlet), not just the first time after startup. In that sample, we think that the JSESSIONID should never be returned to the browser with the session not accessible on a separate request on the same node.
After digging a bit in the WildFly code, we found a possible workaround to force the commit/replication of a new session by calling updateSessionAccessTime(), but it has the side effect of blocking the replication of any session attribute updated after this forced replication until the session is modified by a future request. Note that sendRedirect() has this same bad side effects if any session attribute is updated after the call as it also immediately updates the session access time.
Regards
> Distributable session may not exist after redirect to same node with optimistic locking.
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6489
> URL: https://issues.jboss.org/browse/WFLY-6489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final, 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: wfly-6489-showcase.zip, wildfly-10-session-issue.zip
>
>
> I'm currently working on porting an application running on EAP 6.1 to WildFly 10 and am encountering multiple session/authentication issues with clustering enabled. Our login flow currently starts from a servlet that accepts the credentials, creates the session, then redirect to the welcome page.
> The first time we execute this flow after the startup of a node, the welcome page can't see at all the session created previously.
> - request.getSession() creates yet another session and a new session cookie is returned.
> - request.getSession(false) returns "null"
> On the second attempt, the flow works as expected.
> The issue can be reproduced on both a single node or a two nodes cluster, as long as <distributable /> is enabled in web.xml.
> We are currently using the master build https://ci.jboss.org/hudson/job/WildFly-latest-master/2244/, but the problem has been noticed on 10.0.0-Final and also 8.2.1-Final.
> I attached a sample web application that I used to reproduce the issue. Our standalone.xml is also included with the clustering configuration we've been using for the web/session cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.
by Gabriel Lavoie (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Gabriel Lavoie updated WFLY-6489:
---------------------------------
Attachment: wfly-6489-showcase.zip
Attaching updated sample app to show the issue (wfly-6489-showcase.zip)
> Distributable session may not exist after redirect to same node with optimistic locking.
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6489
> URL: https://issues.jboss.org/browse/WFLY-6489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final, 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: wfly-6489-showcase.zip, wildfly-10-session-issue.zip
>
>
> I'm currently working on porting an application running on EAP 6.1 to WildFly 10 and am encountering multiple session/authentication issues with clustering enabled. Our login flow currently starts from a servlet that accepts the credentials, creates the session, then redirect to the welcome page.
> The first time we execute this flow after the startup of a node, the welcome page can't see at all the session created previously.
> - request.getSession() creates yet another session and a new session cookie is returned.
> - request.getSession(false) returns "null"
> On the second attempt, the flow works as expected.
> The issue can be reproduced on both a single node or a two nodes cluster, as long as <distributable /> is enabled in web.xml.
> We are currently using the master build https://ci.jboss.org/hudson/job/WildFly-latest-master/2244/, but the problem has been noticed on 10.0.0-Final and also 8.2.1-Final.
> I attached a sample web application that I used to reproduce the issue. Our standalone.xml is also included with the clustering configuration we've been using for the web/session cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1098) Equals behaviour faulty when loading sessions after exception
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1098?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1098:
-------------------------------------
For what regards the usage in equality mode I think that another flaw of your test case is that the classes of your domain don't implement the equals/hashcode methods. Fix also that and in case you'll find further problems open another jira ticket, possibly providing a test case similar to the one I pasted in https://issues.jboss.org/browse/DROOLS-1097
> Equals behaviour faulty when loading sessions after exception
> -------------------------------------------------------------
>
> Key: DROOLS-1098
> URL: https://issues.jboss.org/browse/DROOLS-1098
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Attachments: test-standalone.zip
>
>
> This is in a series of debugging and I think a few issues boil down to this:
> https://issues.jboss.org/browse/DROOLS-1093
> https://issues.jboss.org/browse/DROOLS-1097
> This bug demonstrates how two identical sessions with identical input and rules produce a NPE when loading with equals behaviour vs identity behaviour. I am currently battling that issue and looking for a workaround.
> Essentially, you can run the unit tests I attached in the test project: (ExceptionTest)
> testIdentity - passes
> testIdentityWithReload - passes
> testEquals - NPE
> testEqualsWithReload- NPE
> The tests do the same thing:
> * Create new persistent session
> * Load facts into it
> * Run 20 times either reloading the session (depending on the test cases) or using the old session. Each run, insert one fact and run all the rules. Eventually the equals tests (I believe after iteration 2) NPE when trying to deserialise the session. Identity has no issues and functions correctly.
> Let me know if you need anything else and please do let me know if there is a workaround. I am currently exploring the workaround avenue myself as well and will come back here with an update should I find one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1098) Equals behaviour faulty when loading sessions after exception
by Artur Kronenberg (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1098?page=com.atlassian.jira.plugi... ]
Artur Kronenberg edited comment on DROOLS-1098 at 4/6/16 7:56 AM:
------------------------------------------------------------------
That makes sense, thanks.
About must returning the same thing on a call to a method, can that be dynamic?
For example, (I am going to use the model from the other bug)
{code:java}
private LocalDateTime created = LocalDateTime.now();
public boolean isExpired(LocalDateTime toTest) {
return created.isBefore(toTest);
}
{code}
And using a rule that provides toTest:
{code:java}
rule "fact_expiry_automation"
when
$f : ExpirationFact( $time : time );
$e : Expirable( evaluator.isExpired( $time ) == true);
then
log.info("Expiring fact: " + $e);
retract($e);
end
{code}
(Update: created is set once, so the value of created is constant, while the value of toTest is "constant" with regards to the fact that inserts that value)
This, in my head at least, returns the same value each time isExpired is called. This rule however triggers the same behaviour. (I know the comment about the session being dead still stands, just wanting to understand exactly what same result means).
Another follow up question: Does it matter, that identity fixes this problem while equality triggers the exception?
was (Author: pandaadb):
That makes sense, thanks.
About must returning the same thing on a call to a method, can that be dynamic?
For example, (I am going to use the model from the other bug)
{code:java}
public boolean isExpired(LocalDateTime toTest) {
return LocalDateTime.now().isBefore(toTest);
}
{code}
And using a rule that provides toTest:
{code:java}
rule "fact_expiry_automation"
when
$f : ExpirationFact( $time : time );
$e : Expirable( evaluator.isExpired( $time ) == true);
then
log.info("Expiring fact: " + $e);
retract($e);
end
{code}
This, in my head at least, returns the same value each time isExpired is called. This rule however triggers the same behaviour. (I know the comment about the session being dead still stands, just wanting to understand exactly what same result means).
Another follow up question: Does it matter, that identity fixes this problem while equality triggers the exception?
> Equals behaviour faulty when loading sessions after exception
> -------------------------------------------------------------
>
> Key: DROOLS-1098
> URL: https://issues.jboss.org/browse/DROOLS-1098
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Attachments: test-standalone.zip
>
>
> This is in a series of debugging and I think a few issues boil down to this:
> https://issues.jboss.org/browse/DROOLS-1093
> https://issues.jboss.org/browse/DROOLS-1097
> This bug demonstrates how two identical sessions with identical input and rules produce a NPE when loading with equals behaviour vs identity behaviour. I am currently battling that issue and looking for a workaround.
> Essentially, you can run the unit tests I attached in the test project: (ExceptionTest)
> testIdentity - passes
> testIdentityWithReload - passes
> testEquals - NPE
> testEqualsWithReload- NPE
> The tests do the same thing:
> * Create new persistent session
> * Load facts into it
> * Run 20 times either reloading the session (depending on the test cases) or using the old session. Each run, insert one fact and run all the rules. Eventually the equals tests (I believe after iteration 2) NPE when trying to deserialise the session. Identity has no issues and functions correctly.
> Let me know if you need anything else and please do let me know if there is a workaround. I am currently exploring the workaround avenue myself as well and will come back here with an update should I find one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1098) Equals behaviour faulty when loading sessions after exception
by Artur Kronenberg (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1098?page=com.atlassian.jira.plugi... ]
Artur Kronenberg commented on DROOLS-1098:
------------------------------------------
That makes sense, thanks.
About must returning the same thing on a call to a method, can that be dynamic?
For example, (I am going to use the model from the other bug)
{code:java}
public boolean isExpired(LocalDateTime toTest) {
return LocalDateTime.now().isBefore(toTest);
}
{code}
And using a rule that provides toTest:
{code:java}
rule "fact_expiry_automation"
when
$f : ExpirationFact( $time : time );
$e : Expirable( evaluator.isExpired( $time ) == true);
then
log.info("Expiring fact: " + $e);
retract($e);
end
{code}
This, in my head at least, returns the same value each time isExpired is called. This rule however triggers the same behaviour. (I know the comment about the session being dead still stands, just wanting to understand exactly what same result means).
Another follow up question: Does it matter, that identity fixes this problem while equality triggers the exception?
> Equals behaviour faulty when loading sessions after exception
> -------------------------------------------------------------
>
> Key: DROOLS-1098
> URL: https://issues.jboss.org/browse/DROOLS-1098
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Attachments: test-standalone.zip
>
>
> This is in a series of debugging and I think a few issues boil down to this:
> https://issues.jboss.org/browse/DROOLS-1093
> https://issues.jboss.org/browse/DROOLS-1097
> This bug demonstrates how two identical sessions with identical input and rules produce a NPE when loading with equals behaviour vs identity behaviour. I am currently battling that issue and looking for a workaround.
> Essentially, you can run the unit tests I attached in the test project: (ExceptionTest)
> testIdentity - passes
> testIdentityWithReload - passes
> testEquals - NPE
> testEqualsWithReload- NPE
> The tests do the same thing:
> * Create new persistent session
> * Load facts into it
> * Run 20 times either reloading the session (depending on the test cases) or using the old session. Each run, insert one fact and run all the rules. Eventually the equals tests (I believe after iteration 2) NPE when trying to deserialise the session. Identity has no issues and functions correctly.
> Let me know if you need anything else and please do let me know if there is a workaround. I am currently exploring the workaround avenue myself as well and will come back here with an update should I find one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1098) Equals behaviour faulty when loading sessions after exception
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1098?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1098:
-------------------------------------
The issue is not that your rule changes, but that the facts inserted into the working memory does without notifying the engine. Forget about serialization for now. It MUST be ensured that calling a method on a fact will always return the same value OR you MUST notify the engine that the fact is changed. Missing to do that can cause any sort of non-deterministic behaviour.
> Equals behaviour faulty when loading sessions after exception
> -------------------------------------------------------------
>
> Key: DROOLS-1098
> URL: https://issues.jboss.org/browse/DROOLS-1098
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Attachments: test-standalone.zip
>
>
> This is in a series of debugging and I think a few issues boil down to this:
> https://issues.jboss.org/browse/DROOLS-1093
> https://issues.jboss.org/browse/DROOLS-1097
> This bug demonstrates how two identical sessions with identical input and rules produce a NPE when loading with equals behaviour vs identity behaviour. I am currently battling that issue and looking for a workaround.
> Essentially, you can run the unit tests I attached in the test project: (ExceptionTest)
> testIdentity - passes
> testIdentityWithReload - passes
> testEquals - NPE
> testEqualsWithReload- NPE
> The tests do the same thing:
> * Create new persistent session
> * Load facts into it
> * Run 20 times either reloading the session (depending on the test cases) or using the old session. Each run, insert one fact and run all the rules. Eventually the equals tests (I believe after iteration 2) NPE when trying to deserialise the session. Identity has no issues and functions correctly.
> Let me know if you need anything else and please do let me know if there is a workaround. I am currently exploring the workaround avenue myself as well and will come back here with an update should I find one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1098) Equals behaviour faulty when loading sessions after exception
by Artur Kronenberg (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1098?page=com.atlassian.jira.plugi... ]
Artur Kronenberg commented on DROOLS-1098:
------------------------------------------
Interesting - so essentially the issue is that my rule changes?
I am trying to wrap my head around how the NPE is happening. I did not know that deserialising would reassert facts. Even if the rule is reasserted upon deserialising it, wouldn't that just cause it to fire again and not throw an NPE?
> Equals behaviour faulty when loading sessions after exception
> -------------------------------------------------------------
>
> Key: DROOLS-1098
> URL: https://issues.jboss.org/browse/DROOLS-1098
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Attachments: test-standalone.zip
>
>
> This is in a series of debugging and I think a few issues boil down to this:
> https://issues.jboss.org/browse/DROOLS-1093
> https://issues.jboss.org/browse/DROOLS-1097
> This bug demonstrates how two identical sessions with identical input and rules produce a NPE when loading with equals behaviour vs identity behaviour. I am currently battling that issue and looking for a workaround.
> Essentially, you can run the unit tests I attached in the test project: (ExceptionTest)
> testIdentity - passes
> testIdentityWithReload - passes
> testEquals - NPE
> testEqualsWithReload- NPE
> The tests do the same thing:
> * Create new persistent session
> * Load facts into it
> * Run 20 times either reloading the session (depending on the test cases) or using the old session. Each run, insert one fact and run all the rules. Eventually the equals tests (I believe after iteration 2) NPE when trying to deserialise the session. Identity has no issues and functions correctly.
> Let me know if you need anything else and please do let me know if there is a workaround. I am currently exploring the workaround avenue myself as well and will come back here with an update should I find one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1098) Equals behaviour faulty when loading sessions after exception
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1098?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1098:
-------------------------------------
Also consider that as already stated in https://issues.jboss.org/browse/DROOLS-1061 "When a KieSession throws an exception the session itself has to be considered dead and then no longer usable"
> Equals behaviour faulty when loading sessions after exception
> -------------------------------------------------------------
>
> Key: DROOLS-1098
> URL: https://issues.jboss.org/browse/DROOLS-1098
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Attachments: test-standalone.zip
>
>
> This is in a series of debugging and I think a few issues boil down to this:
> https://issues.jboss.org/browse/DROOLS-1093
> https://issues.jboss.org/browse/DROOLS-1097
> This bug demonstrates how two identical sessions with identical input and rules produce a NPE when loading with equals behaviour vs identity behaviour. I am currently battling that issue and looking for a workaround.
> Essentially, you can run the unit tests I attached in the test project: (ExceptionTest)
> testIdentity - passes
> testIdentityWithReload - passes
> testEquals - NPE
> testEqualsWithReload- NPE
> The tests do the same thing:
> * Create new persistent session
> * Load facts into it
> * Run 20 times either reloading the session (depending on the test cases) or using the old session. Each run, insert one fact and run all the rules. Eventually the equals tests (I believe after iteration 2) NPE when trying to deserialise the session. Identity has no issues and functions correctly.
> Let me know if you need anything else and please do let me know if there is a workaround. I am currently exploring the workaround avenue myself as well and will come back here with an update should I find one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month