September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2686) Clean up GWT build for Guvnor

by Geoffrey De Smet (JIRA)

Clean up GWT build for Guvnor ----------------------------- Key: JBRULES-2686 URL: https://jira.jboss.org/browse/JBRULES-2686 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.1.0.FINAL Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: FUTURE * Look into the GWT maven plugin (looks like we don't use it yet?!) * Remove the ANT build files from Guvnor * Remove the generated "cache" files from subversion (if possible) * Get a fast incremental build (from maven + Eclipse + IntelliJ) ** Use GWT shell: changing something and testing it manually should take seconds * Look into automated testings * Look into http://googlewebtoolkit.blogspot.com/2010/08/updated-maven-strategy-for-g... * ... (feel free to suggest) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
8
0 / 0

[JBoss JIRA] Created: (JGRP-897) Anycasting: better use of logical addresses

by Bela Ban (JIRA)

Anycasting: better use of logical addresses ------------------------------------------- Key: JGRP-897 URL: https://jira.jboss.org/jira/browse/JGRP-897 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 See whether logical addresses allow us to handle anycasting more efficiently, ie. handle them at the transport level, and not by sending multiple unicasts -- 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, 10 months

1
9
0 / 0

[JBoss JIRA] Created: (JGRP-1154) FC: separate implementations for multicast and unicast messages

by Bela Ban (JIRA)

FC: separate implementations for multicast and unicast messages --------------------------------------------------------------- Key: JGRP-1154 URL: https://jira.jboss.org/jira/browse/JGRP-1154 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.11 Currently, FC handles both multicast (=group) and unicast messages. This has a few disadvantages: - Complexity - Unicast messages are not dependent on multicast messages (and vice versa), so why should this be different for flow control ? E.g. why should a multicast message block waiting for credits from X because a recent unicast message was sent to X ? - If we have separate flow control protocols for multicasts and unicasts, we can selectively remove one or the other. This is currently not possible Design (see separate documents in ./doc/design): FC_MCAST: ----------------- (see whether some concepts can be borrowed from SFC) Sender: - Every sender has a credits AtomicLong variable - When sending a message and the message length exceeds credits, the sender blocks (until it gets credits from all current group members) - Else credits is decremented by the message length and the message is sent - When credits are received from all current group members, credits is reset to the initial value and all blocked senders are unblocked - When a new member joins, credits is also reset and all blocked senders are unblocked Receiver: - Maintains a hashmap of senders and credits (Map<Address,AtomicLong>) - When a message is received from S, the credits for S are decremented by the message length - If the remaining length is less than the threshold, new credits are sent to S and S's credits are reset to their initial value - When a new member joins, all credits (including the newly joined member) are reset to the initial value FC_UNICAST: -------------------- Sender: - A hashmap of addresses and credits is maintained: every receiver has associated credits - When a message is sent to P, if P's credits minus the message length is less than 0, the sender blocks until it gets new credits from the receiver - Else P's credits are decremented by the message length and the message is sent Receiver: -Same as for FC_MCAST -- 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, 10 months

1
2
0 / 0

[JBoss JIRA] Resolved: (JGRP-1038) FC2

by Bela Ban (JIRA)

[ https://jira.jboss.org/browse/JGRP-1038?page=com.atlassian.jira.plugin.sy... ] Bela Ban resolved JGRP-1038. ---------------------------- Resolution: Won't Fix > FC2 > --- > > Key: JGRP-1038 > URL: https://jira.jboss.org/browse/JGRP-1038 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.11 > > Attachments: FC2.java, FCOverloadTest.java, Results.txt > > > [Email Gray Watson] > So we implemented our own FC2 because of problems with FC. I've been writing > tests and trying (with some success) to reproduce the issues we faced. > Initially when we were doing performance tests in our cluster of ~20 big-ish > linux servers with UDP/FC, we saw severe performance tests with "decent" > sized messages. Often we have large SQL responses which are in the 1+mb > range and can be as high as 10+mb. I decided to write the attached > FCOverloadTest to demonstrate some of the issues and to compare FC and FC2. > The default FC setting max_credits=500000 in udp.xml results in terrible > performance -- 952 seconds to send 10x 5mb messages to 10 hosts (500mb). > Less than optimal. > The simple solution, on the surface, is to increase the credits 1 or 2 > orders of magnitude. 5000000 takes 160 secs, and 50000000 takes 32 secs. > Fine. But this in effect removes most of the flow-control. The larger the > max-credits, the more messages queue up. > What I thought would be a better flow-control model was per-recipient, where > each sender would keep a "water-level" of the outstanding packets needed to > be ack'd. When the water level got too high it would pause the sender until > the receiver had ack'd the water level back down. This is what FC2 tried to > accomplish. I've attached my test results, the FCOverloadTest, and FC2. > FC2 looks to do less UNICAST retransmits, sends fewer packets, and is > faster. It needs some review however. > I'd like to know other folks' experiences with flow-control. Are people > really using the udp.xml settings in production? What message sizes do you > have? > The next step in my testing is to write some unit tests which shut down and > start up notes while the system is loaded with an attempt to reproduce the > cluster pauses with FC that we have seen which would be deadly to our > application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JGRP-1038) FC2

by Bela Ban (JIRA)

[ https://jira.jboss.org/browse/JGRP-1038?page=com.atlassian.jira.plugin.sy... ] Bela Ban commented on JGRP-1038: -------------------------------- Gray withdrew this contribution, as he tested with regular FC and got good enough perf. > FC2 > --- > > Key: JGRP-1038 > URL: https://jira.jboss.org/browse/JGRP-1038 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.11 > > Attachments: FC2.java, FCOverloadTest.java, Results.txt > > > [Email Gray Watson] > So we implemented our own FC2 because of problems with FC. I've been writing > tests and trying (with some success) to reproduce the issues we faced. > Initially when we were doing performance tests in our cluster of ~20 big-ish > linux servers with UDP/FC, we saw severe performance tests with "decent" > sized messages. Often we have large SQL responses which are in the 1+mb > range and can be as high as 10+mb. I decided to write the attached > FCOverloadTest to demonstrate some of the issues and to compare FC and FC2. > The default FC setting max_credits=500000 in udp.xml results in terrible > performance -- 952 seconds to send 10x 5mb messages to 10 hosts (500mb). > Less than optimal. > The simple solution, on the surface, is to increase the credits 1 or 2 > orders of magnitude. 5000000 takes 160 secs, and 50000000 takes 32 secs. > Fine. But this in effect removes most of the flow-control. The larger the > max-credits, the more messages queue up. > What I thought would be a better flow-control model was per-recipient, where > each sender would keep a "water-level" of the outstanding packets needed to > be ack'd. When the water level got too high it would pause the sender until > the receiver had ack'd the water level back down. This is what FC2 tried to > accomplish. I've attached my test results, the FCOverloadTest, and FC2. > FC2 looks to do less UNICAST retransmits, sends fewer packets, and is > faster. It needs some review however. > I'd like to know other folks' experiences with flow-control. Are people > really using the udp.xml settings in production? What message sizes do you > have? > The next step in my testing is to write some unit tests which shut down and > start up notes while the system is loaded with an attempt to reproduce the > cluster pauses with FC that we have seen which would be deadly to our > application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

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

by Scott Marlow (JIRA)

[ https://jira.jboss.org/browse/JBAS-7818?page=com.atlassian.jira.plugin.sy... ] Scott Marlow commented on JBAS-7818: ------------------------------------ Shelly, JBAS-7828 was considered low priority, it could be done but doesn't have to be. For IPV6 support, that deserves a separate jira. Lets talk about it on Monday or create a new jira and assign to me. JMXServiceURL wants square brackets around the IPV6 numeric address and that will help (as per http://www.ietf.org/rfc/rfc2732.txt). > RMIAdaptor replacement based on JSR160 > -------------------------------------- > > Key: JBAS-7818 > URL: https://jira.jboss.org/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: TBD-6.x > > > 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/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

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

by Shelly McGowan (JIRA)

[ https://jira.jboss.org/browse/JBAS-7818?page=com.atlassian.jira.plugin.sy... ] Shelly McGowan commented on JBAS-7818: -------------------------------------- Scott, is this work completed for AS 6.0.0? There is a problem starting AS 6 with IPv6; specifically, the error shown below. This prevents additional testing with IPv6 to proceed. Can you comment on this failure? 4:15:34,374 INFO [JMXConnector] starting JMXConnector on host 3ffe:ffff:100:f101::1:1090 14:15:34,393 ERROR [JMXConnector] Could not start JMXConnector: java.net.MalformedURLException: Bad port number: "": java.lang.NumberFormatException: For input string: "" at javax.management.remote.JMXServiceURL.<init>(JMXServiceURL.java:193) [:1.6.0_13] at org.jboss.system.server.jmx.JMXConnector.start(JMXConnector.java:143) [:6.0.0.20100721-M4 (Build SVNTag:JBoss_6.0.0.20100721-M4 date: 20100723)] > RMIAdaptor replacement based on JSR160 > -------------------------------------- > > Key: JBAS-7818 > URL: https://jira.jboss.org/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: TBD-6.x > > > 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/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-6987) Disable registering of MC bean components as MBeans by default

by jaikiran pai (JIRA)

Disable registering of MC bean components as MBeans by default -------------------------------------------------------------- Key: JBAS-6987 URL: https://jira.jboss.org/jira/browse/JBAS-6987 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Deployers Affects Versions: JBossAS-5.1.0.GA Reporter: jaikiran pai Assignee: jaikiran pai Fix For: JBossAS-6.0.0.Alpha1 Every MC bean that gets deployed, also gets registered as a MBean. These MBeans are optional and only provide debug information. These can by default be disabled. Refer to the referenced forum thread for details. -- 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, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JASSIST-48) Create a common interface to MethodCall & NewExpr

by Guy Korland (JIRA)

Create a common interface to MethodCall & NewExpr ------------------------------------------------- Key: JASSIST-48 URL: http://jira.jboss.com/jira/browse/JASSIST-48 Project: Javassist Issue Type: Feature Request Reporter: Guy Korland Assigned To: Shigeru Chiba MethodCall & NewExpr both have common methods that are not part of the javassist.expr.Expr interface. public String getClassName() public String getSignature() suggested API: abstract public class Invoke extends Expr{ abstract public String getClassName(); abstract public String getSignature(); } public class MethodCall extends Invoke public class NewExpr extends Invoke -- 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

15 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JASSIST-130) GetRefClasses() doesn't include annotation references

by Jesper Pedersen (JIRA)

GetRefClasses() doesn't include annotation references ----------------------------------------------------- Key: JASSIST-130 URL: https://jira.jboss.org/browse/JASSIST-130 Project: Javassist Issue Type: Bug Affects Versions: 3.12.0.GA Reporter: Jesper Pedersen Assignee: Shigeru Chiba When a class references an annotation - f.ex. import javax.resource.spi.Connector @Connector public class MyConnector the call to ctClz.getRefClasses() doesn't include javax.resource.spi.Connector in its list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
2
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 September 2010