[JBoss JIRA] Created: (JBSER-123) StackOverflowError is suppressed
by Karl Brodowsky (JIRA)
StackOverflowError is suppressed
--------------------------------
Key: JBSER-123
URL: https://issues.jboss.org/browse/JBSER-123
Project: JBoss Serialization
Issue Type: Bug
Affects Versions: 1.0.3 GA
Environment: win32 (Microsoft Windows [Version 6.0.6002]), JBoss 5.1.GA, Hibernate 3.3.1.GA
Reporter: Karl Brodowsky
Assignee: Clebert Suconic
I am running JBoss with Hibernate and I am persisting objects that reference each other in a way that allows infinite recursion when following all references without keeping track of which instances have already been visited.
I am getting a gigabyte of log-output and the app-server becomes unusable.
Debugging reveals that this situation occurs during passivation (I can neither confirm nor exclude that it occurs in other situations as well).
Debugging reveals that in method writeSlotWithMethod of RegularObjectPersister (line 127) an exception e is caught and wrapped in an IOException. In the case that I observed this was an InvocationTargetException that itself wraps an StackOverflowError. Without breakpoint a deep structure wrapping of a large number of exceptions with InvocationTargetException containing IOException containing InvocationTargetException occurs.
The primary bug is that the stackOverflow occurs anyway, but I am assuming that that issue is already addressed by other bug reports.
In this piece of code it is important that the InvocationTargetException is handled separately, unpacked and in case the target of the InvocationTargetException is already IOException, RunTimeException or Error it is rethrown as is without (ultimately endless) wrapping in IOException.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JGRP-1252) TCP Gossip Discovery Issue
by Grahame Rogers (JIRA)
TCP Gossip Discovery Issue
--------------------------
Key: JGRP-1252
URL: https://jira.jboss.org/browse/JGRP-1252
Project: JGroups
Issue Type: Bug
Affects Versions: 2.11
Environment: Windows XP and Solaris 5.10
Reporter: Grahame Rogers
Assignee: Bela Ban
Fix For: 2.11.1
I run the chat demo app that was shipped with an older version of Jgroups. Using tcp transport, with tcpgossip for discovery I start up 2 instances of the chat application. I then restart the gossip server and also another instance of the chat application. The 3rd instance of the chat application receives a view update (membershipListener.viewAccepted) only the logical name of one of the 2 previous instances of the chat client is incorrect. I have detailed the results in: http://old.nabble.com/TCPGossip-Discovery-Issue-td30227966.html
I will attach the test client to this bug report.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBRULES-2912) Drools Planner Divide By Zero Error
by David Faulkner (JIRA)
Drools Planner Divide By Zero Error
-----------------------------------
Key: JBRULES-2912
URL: https://issues.jboss.org/browse/JBRULES-2912
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-planner
Affects Versions: 5.1.1.FINAL
Environment: Windows, Intel desktop-class, Java6 (bug is not environment-specific)
Reporter: David Faulkner
Assignee: Mark Proctor
In org.drools.palnner.core.localsearch.DefaultLocalSearchSolver::solvingEnded, there is potentially a divide by zero that occurs on the line:
long averageCalculateCountPerSecond = localSearchSolverScope.getCalculateCount() * 1000L / timeMillisSpend;
if timeMillisSpend is zero. Although in theory the likelihood of this occurring in practically nothing, we have actually seen it occur on a POC project with long running Planner jobs. An appropriate guard should be added to this calculation to ensure that this error cannot occur.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBRULES-2909) Build: development setup howto's, tips & tricks in the README.txt file for git, maven, eclipse, intellij, ...
by Geoffrey De Smet (JIRA)
Build: development setup howto's, tips & tricks in the README.txt file for git, maven, eclipse, intellij, ...
-------------------------------------------------------------------------------------------------------------
Key: JBRULES-2909
URL: https://issues.jboss.org/browse/JBRULES-2909
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBRULES-2911) Planner: simulated annealing should work for planning problems with many hard constraints broken
by Geoffrey De Smet (JIRA)
Planner: simulated annealing should work for planning problems with many hard constraints broken
------------------------------------------------------------------------------------------------
Key: JBRULES-2911
URL: https://issues.jboss.org/browse/JBRULES-2911
Project: Drools
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Priority: Minor
Fix For: 5.2.0.M2
This code is bad in SimulatedAnnealingAcceptor:
// TODO don't abuse translateScoreToGraphValue
// TODO do hard and soft separately and then average their acceptChance
Double diff = localSearchSolverScope.getScoreDefinition().translateScoreToGraphValue(scoreDifference);
if (diff == null) {
// more hard constraints broken, ignore it for now
return 0.0;
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years