April 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1944) Adding crontab type functionality for repetitive rules.

by Griz frf (JIRA)

Adding crontab type functionality for repetitive rules. ------------------------------------------------------- Key: JBRULES-1944 URL: https://jira.jboss.org/jira/browse/JBRULES-1944 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-api Affects Versions: FUTURE Reporter: Griz frf Assignee: Mark Proctor A convinient helper function to schedule rule executions in a similar manner to the cron utility would be useful. My specific use case is for a long running session to periodically write out data to a persistence store (db, file, etc) The current code for this is as follows : rule "DBpoll" duration(30s) when $d:String(toString=="Run") then System.out.println("30seconds elapsed"); Database.dosomething(); modify($d){}; end -------------------------------- session.insert(new String("Run")); --------------------------------- While this method does work, it requires the external dummy object trigger. In dynamically generated rules and rules pulled in from libraries, etc (not under the current developers control) it is difficult to ensure that a suibtable trigger is available. Therefore a cron like function would solve this issue. I envision the EVERY keyword and possibly a COUNT or for loop style format rule "DBpoll" EVERY(30s, 100) <-- means every 30 seconds for 100 iterations. or EVERY(30s, 10m) <-- every 30 seconds for 10 mins then System.out.println("30seconds elapsed"); Database.dosomething(); end -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2431) Typo on Drools Fusion website

by Bruce Mitchener (JIRA)

Typo on Drools Fusion website ----------------------------- Key: JBRULES-2431 URL: https://jira.jboss.org/jira/browse/JBRULES-2431 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Bruce Mitchener Assignee: Mark Proctor http://www.jboss.org/drools/drools-fusion.html In the TOC, the 2nd entry reads: What is Event Processin (or Complex Event Processing, CEP)? But should read: What is Event Processing (or Complex Event Processing, CEP)? Just a small typo... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1804) Logical insertion lingers after the rule that inserted it no longer supports it (with testcase patch)

by Geoffrey De Smet (JIRA)

Logical insertion lingers after the rule that inserted it no longer supports it (with testcase patch) ----------------------------------------------------------------------------------------------------- Key: JBRULES-1804 URL: https://jira.jboss.org/jira/browse/JBRULES-1804 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.0.0.M2 Reporter: Geoffrey De Smet Assignee: Edson Tirelli Priority: Critical Fix For: 5.0.0.M3 This one got me headscratching for a while, untill I realized what the problem is. Tim reported on the mailing list he ran into it to. I've commmited a testcase in subversion, in TruthMaintenanceTest, called disabled_testLogicalInsertionsModifySameRuleGivesDifferentLogicalInsertion Remove the "disabled_" to enable it and try it out. Here's what happens in the testcase: 3 sensors with tempature 100, 200 and 200 are inserted. There's a rule which logically inserts all encountered tempatures, so 100 and 200. Then the first sensor modifies to a tempature of 150. As it turns out, the encoutered tempatures should be 150 and 200 now, but instead it's 100, 150 and 200. Even though there is no sensor that has a tempature of 100. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

4
17
0 / 0

[JBoss JIRA] Created: (JBRULES-2468) Task with large content does not get persisted correctly

by Kris Verlaenen (JIRA)

Task with large content does not get persisted correctly -------------------------------------------------------- Key: JBRULES-2468 URL: https://jira.jboss.org/jira/browse/JBRULES-2468 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-process-task Affects Versions: 5.1.0.M1 Reporter: Kris Verlaenen Assignee: Kris Verlaenen Fix For: 5.1.0.M2 When a task with content > 1024 bytes is written, only the first 1024 bytes are actually stored in the task service. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7886) AJP connection is left as CLOSE_WAIT

by NRI OSSC (JIRA)

AJP connection is left as CLOSE_WAIT ------------------------------------ Key: JBAS-7886 URL: https://jira.jboss.org/jira/browse/JBAS-7886 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.2.3.GA Environment: 1) CentOS 5.4 2) Apache 2.2.13 + mod_jk 1.2.28 3) jdk1.5.0_21 4) JBoss AS 4.2.3.GA Reporter: NRI OSSC Assignee: Remy Maucherat The AJP connections of the status of CLOSE_WAIT increase when I carry out multiple processing from a browser in the environment mentioned above. When surpassed open files of the OS, "java.net.SocketException: Too many open files" occurs. This issue does not occur with the load tools such as JMeter. I evade this issue with JBoss Native. This is a problem same as https://jira.jboss.org/jira/browse/JBPAPP-366. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (SECURITY-492) JBossPolicySetLocator should gracefully handle policies

by Anil Saldhana (JIRA)

JBossPolicySetLocator should gracefully handle policies ------------------------------------------------------- Key: SECURITY-492 URL: https://jira.jboss.org/jira/browse/SECURITY-492 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JBossXACML Affects Versions: jbossxacml_2.0.5.CR2 Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: jbossxacml_2.0.5.CR3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (SECURITY-490) JBossAuthorizationManager-<JBossAuthorizationContext.authorize call has an unnecessary lock

by Anil Saldhana (JIRA)

JBossAuthorizationManager-<JBossAuthorizationContext.authorize call has an unnecessary lock ------------------------------------------------------------------------------------------- Key: SECURITY-490 URL: https://jira.jboss.org/jira/browse/SECURITY-490 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: PicketBox_v3_0_beta4, JBossSecurity_2.0.4.SP3 Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: JBossSecurity_2.0.4.SP4, PicketBox_v3_0_beta5 Thanks to Marcus Moyses for detecting this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
7
0 / 0

[JBoss JIRA] Created: (JGRP-1180) OutOfMemoryError

by Peter Kormos (JIRA)

OutOfMemoryError ---------------- Key: JGRP-1180 URL: https://jira.jboss.org/jira/browse/JGRP-1180 Project: JGroups Issue Type: Bug Affects Versions: 2.8 Environment: 2.8.0.GA Reporter: Peter Kormos Assignee: Bela Ban Hi Guys, I wrote a simple program. public testbed() throws Exception { JChannel channel = new JChannel(); channel.connect("channelName"); for (int i = 0; i < 100000000; i++) { Message msg = new Message( null, null, "Test"); channel.send(msg); // Thread.sleep(10); if (i % 1000 == 0) System.out.print("."); } } When I run it with java -Xmx8m -XX:+HeapDumpOnOutOfMemoryError -cp .;jgroups-all.jar testbed not always, but quite often it dies with OutOfMemoryError When I look at the heap dump with jhat, for "Instance Counts" it tells me 22036 instances of class org.jgroups.Message 22036 instances of class org.jgroups.protocols.pbcast.NakAckHeader 22036 instances of class org.jgroups.util.Headers 21316 instances of class org.jgroups.Event 21314 instances of class org.jgroups.util.Queue$Element 304 instances of class org.jgroups.util.UUID Why are there so many message objects stuck in memory? java org.jgroups.Version prints Version: 2.8.0.GA CVS: $Id: Version.java,v 1.81 2009/12/01 10:31:13 belaban Exp $ I'm using Windows Xp with 1.6 JDK -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-7887) Upgrade JBoss AOP to 2.2.0

by Flavia Rainone (JIRA)

Upgrade JBoss AOP to 2.2.0 -------------------------- Key: JBAS-7887 URL: https://jira.jboss.org/jira/browse/JBAS-7887 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: AOP Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: JBossAS-6.0.0.M3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBAS-7818) RMIAdaptor replacement based on JSR160

by Scott Marlow (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-7818?page=com.atlassian.jira.plug... ] Scott Marlow commented on JBAS-7818: ------------------------------------ Thomas, will do. For now, try changing: RMIAdaptor adaptor = (RMIAdaptor) ctx.lookup("jmx/rmi/RMIAdaptor"); To: MBeanServerConnection adaptor = (MBeanServerConnection) ctx.lookup("jmx/rmi/RMIAdaptor"); > RMIAdaptor replacement based on JSR160 > -------------------------------------- > > Key: JBAS-7818 > URL: https://jira.jboss.org/jira/browse/JBAS-7818 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMX > Reporter: Scott M Stark > Assignee: Scott Marlow > Fix For: JBossAS-6.0.0.M3 > > > A replacement for the proprietary RMIAdaptor is needed that supports authentication, authorization and SSL. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2010