May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBMESSAGING-353) ConnectionConsumerTest.testRedeliveryTransacted() fails on Mac OSX 10.4.6 but passes on Windows

by Aaron Walker (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-353?page=comments#action_12... ] Aaron Walker commented on JBMESSAGING-353: ------------------------------------------ I tested this on my intel iMac and the test now passes with the following setup Java Version 1.5.0_07 Java Vendor Apple Computer, Inc. Java VM Name Java HotSpot(TM) Client VM Java VM Version 1.5.0_07-87 Java VM Info mixed mode, sharing OS Name Mac OS X OS Version 10.4.9 OS Arch i386 I tested this against the Branch_1_2_0_SP branch. I don't have my old powerbook with me right now but I suspect it will also pass. Should all the test pass on the Branch_1_2_0_SP branch ????? > ConnectionConsumerTest.testRedeliveryTransacted() fails on Mac OSX 10.4.6 but passes on Windows > ----------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-353 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-353 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Facade, Tests and Performance > Affects Versions: 1.0.0, 1.0.1.CR1 > Environment: mac osx 10.4.6 > JDK 1.4.2_09 > JDK 1.5.0_04 > Reporter: Aaron Walker > Assigned To: Aaron Walker > Fix For: 2.0.0 Beta 1 > > Attachments: messaging-tests.trace.log > > Original Estimate: 3 days > Remaining Estimate: 3 days > > The testRedeliveryTransacted fail with the following: > 1) testRedeliveryTransacted(org.jboss.test.messaging.jms.ConnectionConsumerTest)junit.framework.AssertionFailedError: Didn't receive correct messages > at org.jboss.test.messaging.jms.ConnectionConsumerTest.testRedeliveryTransacted(ConnectionConsumerTest.java:224) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at org.jboss.test.messaging.tools.junit.SelectiveTestRunner.main(SelectiveTestRunner.java:58) > The issue revolves around the sess.rollback around line 433 in that after the rollback and the 3 messages get redelivered and on the 3rd message the following if (!tm.getJMSRedelivered()) at line 481 evaluates to true in that the getJMSRedelivered() is false when it should be true. By placing a 1ms sleep just prior to the rollback you can get the test to pass. So after my initial investigation It appears that it may be some sort of threading issue that shows up on my mac. > I will attached the TRACE log for this If you look at line 765 of the log it shows that the delivery count for the message is 0 when it should be 1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4155) run.conf used from other scripts than run.sh

by Tobias Frech (JIRA)

run.conf used from other scripts than run.sh -------------------------------------------- Key: JBAS-4155 URL: http://jira.jboss.com/jira/browse/JBAS-4155 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-4.0.5.GA Environment: Linux/Unix Reporter: Tobias Frech Priority: Minor Configuration in run.conf is used from other scripts than run.sh. For example shutdown.sh or twiddle.sh include it. They should not because that leads to undesireable or even dangeous effects. Details: Editing run.conf an including JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y" to enable remote debugging Starting the server: sh run.sh -c minimal Stopping the server produces: sh shutdown.sh -S ERROR: transport error 202: bind failed: Address already in use ["transport.c",L41] ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) ["debugInit.c",L497] JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initializedFATAL ERROR in native method: JDWP No transports initialized, jvmtiError=JVMTI_ERROR_INTERNAL(113) This may get worse if someone uses a -Xms3000m setting on a server that only has 4GB of memory. Potentially leading to a swap out of a production system to disk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

4
9
0 / 0

[JBoss JIRA] Resolved: (EJBTHREE-501) Enhance clustered sfsb testsuite

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-501?page=all ] Brian Stansberry resolved EJBTHREE-501. --------------------------------------- Fix Version/s: AS 4.2.0 GA (was: EJB 3.0 RC11 - FD) Resolution: Done I'm sure we'll come up with more tests over time, but at this point I think the clustered SFSB testsuite is in good enough shape to close this issue. > Enhance clustered sfsb testsuite > -------------------------------- > > Key: EJBTHREE-501 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-501 > Project: EJB 3.0 > Issue Type: Task > Components: Clustering > Reporter: Ben Wang > Assigned To: Brian Stansberry > Priority: Minor > Fix For: AS 4.2.0 GA > > > Currently we only have a simple test on clustered sfsb. We will need to expand the tests such as passivation/activation, etc. I will add more as I am working towards fine-grained impl. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-165) Expose Editor settings in preferences window

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-165?page=all ] Mark Proctor updated JBRULES-165: --------------------------------- Fix Version/s: 4.0.0.MR3 (was: 4.0.0.MR2) > Expose Editor settings in preferences window > -------------------------------------------- > > Key: JBRULES-165 > URL: http://jira.jboss.com/jira/browse/JBRULES-165 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eclipse IDE > Reporter: Mark Proctor > Assigned To: Kris Verlaenen > Fix For: 4.0.0.MR3 > > > settings like tabs and spaces need to be configurable and exposed in window->preferences. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-261) Mismatched types in field constraints

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-261?page=all ] Mark Proctor updated JBRULES-261: --------------------------------- Fix Version/s: 4.0.0.MR3 (was: 4.0.0.MR2) > Mismatched types in field constraints > ------------------------------------- > > Key: JBRULES-261 > URL: http://jira.jboss.com/jira/browse/JBRULES-261 > Project: JBoss Rules > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Rule Assemply/SPI > Affects Versions: 3.0.1 > Reporter: Michael Neale > Assigned To: Mark Proctor > Priority: Minor > Fix For: 4.0.0.MR3 > > > Problem: If a rule compares two fields and one of them is a char and the > other one is a String, the match is always negative. No type-mismatch error > or warning is displayed. This can be quite confusing. The attached Eclipse > project illustrates this problem. > Suggested Solution: If all information is available at compile-time an error > should be generated on type mismatches. Otherwise there should be a warning > during run-time and maybe a type conversion attempt. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-265) Automatic DSL populator (wizard/utility)

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-265?page=all ] Mark Proctor updated JBRULES-265: --------------------------------- Fix Version/s: 4.0.0.MR3 (was: 4.0.0.MR2) > Automatic DSL populator (wizard/utility) > ---------------------------------------- > > Key: JBRULES-265 > URL: http://jira.jboss.com/jira/browse/JBRULES-265 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eclipse IDE > Reporter: Michael Neale > Assigned To: Michael Neale > Fix For: 4.0.0.MR3 > > > This would introspect selected objects, and create LHS and RHS DSL mappings to access each and every field. > For LHS, something like > There is Person {p} > Person {p} age is less then {age} > Person {p} age is greater then {age} > .. and so on (depending on field data type). > ..possibly generate a mapping that includes all fields in one line > For RHS, something like > Set age of Person {p} to {age} > etc etc... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-135) Group Rules in outline view

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-135?page=all ] Mark Proctor updated JBRULES-135: --------------------------------- Fix Version/s: 4.0.0.MR3 (was: 4.0.0.MR2) > Group Rules in outline view > --------------------------- > > Key: JBRULES-135 > URL: http://jira.jboss.com/jira/browse/JBRULES-135 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eclipse IDE > Reporter: Mark Proctor > Assigned To: Kris Verlaenen > Fix For: 4.0.0.MR3 > > > When rules are placed into AgendaGroups we should show this in a tree. default agenda group is MAIN. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-264) Fine grained Meta-Data driven intelligent parser

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-264?page=all ] Mark Proctor updated JBRULES-264: --------------------------------- Fix Version/s: 4.0.0.MR3 (was: 4.0.0.MR2) > Fine grained Meta-Data driven intelligent parser > ------------------------------------------------ > > Key: JBRULES-264 > URL: http://jira.jboss.com/jira/browse/JBRULES-264 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Drl Parser/Builder > Reporter: Mark Proctor > Assigned To: Bob McWhirter > Fix For: 4.0.0.MR3 > > > Currently we use the same API to parse and compile packages as we do for the IDE. This is proving quite heavy. I propose that we make an additional API for IDE integration that is fine grained and meta data driven. I believe that Eclipse has extensive meta data capabilities, which it stores on disk, we should really try and leverage this. Although the core API should try and be independent, so other IDEs can leverage it. > 1) Split the main document up into package, imports, globals, functions and rules ? but do not parse contents. > a. Maybe we will build up the meta-data for imports and globals at this stage, as I imagine that?s easy. > b. Record, as meta data, the start and end line numbers, i.e. the range, for all sections. > > 2) Tokenise all expressions and blocks ? do not loose line numbers though, so will need to pad. > a. Record, as meta data, the start and end line/col numbers, i.e. the range, for all expressions and blocks. > > 3) Parse each Rule > a. Validate Conditional Element and Field Constraint structure > b. Validate Columns and Fields ? record this in meta data. So we know the dependant classes and fields for this rule. > c. Record Column and Field bindings as meta data ? as used for expressions. > d. Validate operators and the RHS value type, checks it?s valid with LHS and operator. > > 4) Determine required declarations for each expression and record as meta data > a. If we can it might be nice to also determine dependant classes from the Imports and Globals , beyond declarations, and record as meta data. > > 5) Compile each expression and block, using a helper util, record the errors as meta data and then forget the compiled .class > 6) Develop intelligent balanced-text recovery. So when scanning 1) and 2) we need to check for balanced text, if we detect incorrect balancing we then mark that section as invalid and find the start of the next valid section ? nothing inside those invalid sections will be parsed. > a. i.e. if we have an invalid expression, incorrect number of brackets on the LHS of the rule, we try and recover to the next valid area, ideally this would be the next valid conditional element ? but that may be hard and it could be the RHS of the rule. Start simple, make it coarse, and intelligent fine grained can be added later. > > 7) Intelligent re-parsing for project wide changes. > a. We have class dependencies in meta-data for the various sections ? and also fields in constraints. So we can determine errors from the meta data, without having to reparse. > b. In the case of expressions we can use the meta data, to avoid re-compiling. I guess if the changes are too dramatic then we can recompile the expression/consequence. We have the ranges in meta data for the dependant sections, so we can rescan to suck up the expression, without having to parse the entire document > c. In document editing we only recompile expressions consequence if the user edits them ? again we should know that we are in an expression, we know the start so we scan from the start of t he expression/block to the end and compile. Avoid reparse the entire document or even the rule. If bindings are changed we can also determine the dependant expressions and recompile to get errors. > > > I am sure there is a lot more complexity to this and missed stages. But it should be enough to show you the direction I want to take this. So we are extensively using meta data to minimise the re-parsing and re-compiling. We are also using meta data to localise the areas that we do need to re-parse for changes. The key to this is always being able to know exactly what we are editing. We may have to extend the descr, or create a new structure to handle meta data driven parsing. Non of this replaces the existing ruleparse/descry/packagebuidler implementations which are still required for compiling and deploying real rule bases - although hopefully we can leverage parts from both, to avoid duplication. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-347) context assist help with f1

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-347?page=all ] Mark Proctor updated JBRULES-347: --------------------------------- Fix Version/s: 4.0.0.MR3 (was: 4.0.0.MR2) > context assist help with f1 > --------------------------- > > Key: JBRULES-347 > URL: http://jira.jboss.com/jira/browse/JBRULES-347 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assigned To: Kris Verlaenen > Fix For: 4.0.0.MR3 > > > f1 should show appropriate help. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-352) DRLEditor to have seperate tab for DSL style DRL editing, and vanilla DRL editing

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-352?page=all ] Mark Proctor updated JBRULES-352: --------------------------------- Fix Version/s: 4.0.0.MR3 (was: 4.0.0.MR2) > DRLEditor to have seperate tab for DSL style DRL editing, and vanilla DRL editing > --------------------------------------------------------------------------------- > > Key: JBRULES-352 > URL: http://jira.jboss.com/jira/browse/JBRULES-352 > Project: JBoss Rules > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Eclipse IDE > Affects Versions: 3.0.1 > Reporter: Michael Neale > Assigned To: Kris Verlaenen > Fix For: 4.0.0.MR3 > > > Editor is a bit complex mixing in DSL and DRL features. Best to seperate it out. There will also be an API for expanding a DSL style DRL into vanilla DRL for debugging. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2007