December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2621) Zero Timeout Stateful EJB Leak (clustered)

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-2621: ---------------------------------- Summary: Zero Timeout Stateful EJB Leak (clustered) Key: WFLY-2621 URL: https://issues.jboss.org/browse/WFLY-2621 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Reporter: Paul Ferraro Assignee: Eduardo Martins Fix For: 8.0.0.CR1 Stateful EJB instances are not removed from cache upon release, if the timeout is zero. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2621) Zero Timeout Stateful EJB Leak (clustered)

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-2621?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned WFLY-2621: ---------------------------------- Assignee: Paul Ferraro (was: Eduardo Martins) > Zero Timeout Stateful EJB Leak (clustered) > ------------------------------------------ > > Key: WFLY-2621 > URL: https://issues.jboss.org/browse/WFLY-2621 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 8.0.0.CR1 > > > Stateful EJB instances are not removed from cache upon release, if the timeout is zero. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2621) Zero Timeout Stateful EJB Leak (clustered)

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-2621?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-2621: ------------------------------- Description: Stateful EJB instances are not removed from cache upon release, if the timeout is zero. Apply WFLY-2590 fix to distributable cache. was:Stateful EJB instances are not removed from cache upon release, if the timeout is zero. > Zero Timeout Stateful EJB Leak (clustered) > ------------------------------------------ > > Key: WFLY-2621 > URL: https://issues.jboss.org/browse/WFLY-2621 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 8.0.0.CR1 > > > Stateful EJB instances are not removed from cache upon release, if the timeout is zero. > Apply WFLY-2590 fix to distributable cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-365) Rule attribute for adding inverse of consequence as rule condition

by Adar Dembo (JIRA)

[ https://issues.jboss.org/browse/DROOLS-365?page=com.atlassian.jira.plugin... ] Adar Dembo commented on DROOLS-365: ----------------------------------- I don't see the problem with modifications to multiple facts: you could condition on the NOT of the logical AND of all facts. Or the logical OR; I think both approaches are defensible. As for your second example, what's the issue with multiple rules asserting the same fact? In any case, I think the biggest challenge to implementation is that the rule consequence is a snippet of Java, and thus can do absolutely anything. For example, it could conditionally assert a fact. How do you modify the rule then? Also conditionally? Based on runtime input? It seems really challenging. The example that actually drove me to file this bug looks something like this: {noformat} rule "1" when accumulate (Foo($type : type, $value : value), $total : sum($value)) then insert(new Bar($type, $total)); end rule "handle all Bars of type first" when $bar : Bar(type == 'first', $total : total) ... then retract($bar); end rule "handle all Bars of type second" when $bar : Bar(type == 'second', $total : total) ... then retract($bar); end rule "generic rule to handle all leftover Bars" salience -1 // let custom Bar rules fire first when $bar : Bar($total : total) ... then retract($bar); end {noformat} The flow here is to convert the sum of all Foos (of a given type) into a Bar. Subsequently, there's a rule to handle each type of Bar, with a generic rule to handle Bars without a custom rule. To get that fallthrough behavior I need: # Salience -1 on the generic rule, so it fires last. # Retraction of each Bar as it's processed. However, the retraction causes the summation rule to reactivate, unless I add an explicit {{not Bar(type == $type)}} condition to the rule. Granted, in this case, I suppose the feature request mentioned here wouldn't work, because it'd add {{not Bar(type == $type, total == $total)}}, which would allow the rule to reactivate. For this example, I don't think equality-based assertion will solve my problem; fundamentally the retraction of a Bar causes us to reevaluate the accumulate rule. Likewise, I don't think @propertyReactive will help either; the issue here isn't with modifying a single property, but with removing an entire fact. > Rule attribute for adding inverse of consequence as rule condition > ------------------------------------------------------------------ > > Key: DROOLS-365 > URL: https://issues.jboss.org/browse/DROOLS-365 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Adar Dembo > Assignee: Mark Proctor > > I have quite a few rules that look like this: > {noformat} > rule "if foo then bar" > when > Foo($a : a, $b : b) > not Bar(a == $a, b == $b) > then > insert(new Bar($a, $b)); > end > {noformat} > This is a fairly common pattern for me: a rule should not activate if the facts generated by its consequence were already asserted. It's a pattern I use extensively to generate linear (i.e. non-repeating) workflows. > Ideally I'd be able to express it as follows: > {noformat} > rule "if foo then bar" > condition-on-inverse-of-consequence > when > Foo($a : a, $b : b) > then > insert(new Bar($a, $b)); > end > {noformat} > And {{condition-on-inverse-of-consequence}} would cause Drools to generate the right kind of condition, which would be the inverse of the fact changes made by the consequence. > I think {{lock-on-active}} is similar but harsher: it prevents the rule from firing a second time altogether, regardless of input. At least, that's based on my reading of the docs. In my example, that would be equivalent to {{not Bar()}} condition in the rule, which is stricter than {{not Bar(a == $a, b == $b)}}. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2272) component upgrade to Hibernate ORM 4.3.0.CR2

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2272?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-2272. ------------------------------ > component upgrade to Hibernate ORM 4.3.0.CR2 > -------------------------------------------- > > Key: WFLY-2272 > URL: https://issues.jboss.org/browse/WFLY-2272 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 8.0.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-2593: ------------------------------------ No need to apologize, this was an excellent bug report (+10 for providing a test case ready to be used). Also, your test case didn't work on WildFly right away, Brian had to fix WFLY-2609 first. So, you also helped us to find that. {quote} I wonder how can I view the statistics in WildFly. I see there is no "hibernate-persistence-unit" under /deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa. Was the removal of this functionallity intended ? {quote} This is the WFLY-2609 bug that you also helped me find! :-) > Memory leak in JBoss AS / Hibernate JPA integration > --------------------------------------------------- > > Key: WFLY-2593 > URL: https://issues.jboss.org/browse/WFLY-2593 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: No Release > Environment: JBoss 7.1.1 > JBoss EAP 6.2 beta > Reporter: Michael Kozak > Assignee: Scott Marlow > Priority: Critical > Fix For: No Release > > Attachments: jmxp.ear.ear, jmxp.tar.gz > > > The leak exists in AS integration code with Hibernate JPA. > When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements. > The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found. > Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do. > This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ] Ondrej Zizka edited comment on WFLY-2426 at 12/6/13 1:02 PM: ------------------------------------------------------------- Ok after some feedback, let's reconsider how to approach this. Maybe version.txt is okay to be reused with different format. Would that bring anything? << Jimmy The format could be XML as well. But I'd not recommend ISO/IEC 19770-2 as that doesn't solve anything for our use case. Maybe a POM format could be (mis)used with just G:A:V[:C]? We could put the info into one file, not using the layer names for version-<layer_name>.<extension> << Paul, Fernando * Does the underlying software need to be identified? I.e. if it's SOA, should the file also say it's EAP for the tools which do not know SOA? << Max * Should a timestamp be included? E.g. to differentiate between release candidates which all have ".GA" * Is it okay to change the file for layered products? That could be error-prone. Or rather add another file << SOA Productization Going to get some more feedback from Teams / people interested in this. was (Author: ozizka): Ok after some feedback, let's reconsider how to approach this. Maybe version.txt is okay to be reused with different format. Would that bring anything? << Jimmy The format could be XML as well. But I'd not recommend ISO/IEC 19770-2 as that doesn't solve anything for our use case. Maybe a POM format could be (mis)used with just G:A:V[:C]? We could put the info into one file, not using the layer names for version-<layer_name>.<extension> << Paul, Fernando Going to get some more feedback from Teams / people interested in this. > Easily accessible static information describing the release > ----------------------------------------------------------- > > Key: WFLY-2426 > URL: https://issues.jboss.org/browse/WFLY-2426 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Server > Reporter: Brian Stansberry > Assignee: Ondrej Zizka > Labels: build, integration, jbds, layers, version > Fix For: 8.0.0.CR1 > > > Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly. > This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build. > The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity. > The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution? > The solution to this issue should consider the implications for the patching tool. > [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ] Ondrej Zizka commented on WFLY-2426: ------------------------------------ Ok after some feedback, let's reconsider how to approach this. Maybe version.txt is okay to be reused with different format. Would that bring anything? << Jimmy The format could be XML as well. But I'd not recommend ISO/IEC 19770-2 as that doesn't solve anything for our use case. Maybe a POM format could be (mis)used with just G:A:V[:C]? We could put the info into one file, not using the layer names for version-<layer_name>.<extension> << Paul, Fernando Going to get some more feedback from Teams / people interested in this. > Easily accessible static information describing the release > ----------------------------------------------------------- > > Key: WFLY-2426 > URL: https://issues.jboss.org/browse/WFLY-2426 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Server > Reporter: Brian Stansberry > Assignee: Ondrej Zizka > Labels: build, integration, jbds, layers, version > Fix For: 8.0.0.CR1 > > > Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly. > This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build. > The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity. > The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution? > The solution to this issue should consider the implications for the patching tool. > [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2620) Zero Timeout Stateful EJB Leak (clustered)

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-2620: ---------------------------------- Summary: Zero Timeout Stateful EJB Leak (clustered) Key: WFLY-2620 URL: https://issues.jboss.org/browse/WFLY-2620 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Reporter: Paul Ferraro Assignee: Eduardo Martins Fix For: 8.0.0.CR1 Stateful EJB instances are not removed from cache upon release, if the timeout is zero. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration

by Michael Kozak (JIRA)

[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ] Michael Kozak commented on WFLY-2593: ------------------------------------- Sorry Scott I didn't check the WildFly at all. I just assumed this issue tracker is for JBoss 7 AS too since the original space is closed. I already created an issue in Red Hat issue tracker. The link is available at this page in "Bugzilla References". I wonder how can I view the statistics in WildFly. I see there is no "hibernate-persistence-unit" under /deployment=jmxp.ear.ear/subdeployment=jmxp.ejb.jar/subsystem=jpa. Was the removal of this functionallity intended ? > Memory leak in JBoss AS / Hibernate JPA integration > --------------------------------------------------- > > Key: WFLY-2593 > URL: https://issues.jboss.org/browse/WFLY-2593 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: No Release > Environment: JBoss 7.1.1 > JBoss EAP 6.2 beta > Reporter: Michael Kozak > Assignee: Scott Marlow > Priority: Critical > Fix For: No Release > > Attachments: jmxp.ear.ear, jmxp.tar.gz > > > The leak exists in AS integration code with Hibernate JPA. > When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements. > The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found. > Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do. > This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2013