September 2010 - jboss-jira - Jboss List Archives

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

14 years, 3 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

14 years, 3 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

14 years, 3 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

14 years, 3 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

14 years, 3 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

14 years, 3 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

14 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-8272) Change property name on JSFUrlIntegrationDeployer

by Stan Silvert (JIRA)

Change property name on JSFUrlIntegrationDeployer ------------------------------------------------- Key: JBAS-8272 URL: https://jira.jboss.org/browse/JBAS-8272 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 6.0.0.M4 Reporter: Stan Silvert Assignee: Stan Silvert Fix For: 6.0.0.CR1 Change property name from JSFImplName to JSFConfigName. This makes it consistent with the property names on JSFImplManagementDeployer. -- 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

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8405) Add MyFaces 2.0 support to JSF Deployer

by Stan Silvert (JIRA)

Add MyFaces 2.0 support to JSF Deployer --------------------------------------- Key: JBAS-8405 URL: https://jira.jboss.org/browse/JBAS-8405 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JSF Affects Versions: 6.0.0.M4 Reporter: Stan Silvert Assignee: Stan Silvert Fix For: 6.0.0.CR1 This will be included in CR1. There are some optimizations for annotation scanning that will be implemented in MyFaces 2.0.2, but we will ship MyFaces 2.0.1 for now. Mojarra will remain as the default JSF implementation. -- 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

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8401) exception is thrown by javax.ejb.EJBLocalObject.isIdentical -- ejb2.x

by Thunder Lei (JIRA)

exception is thrown by javax.ejb.EJBLocalObject.isIdentical -- ejb2.x --------------------------------------------------------------------- Key: JBAS-8401 URL: https://jira.jboss.org/browse/JBAS-8401 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2, EJB3 Affects Versions: JBossAS-5.0.0.GA Environment: Microsoft Windows XP [Version 5.1.2600] jdk160_10 Reporter: Thunder Lei Assignee: Alexey Loubyansky I am new to JBoss community. If I don't report the issues correctly, pls help correct me. I develop a stateless session bean, in which EJB2.x and EJB3 interfaces coexist. In short, it works, but with two issues. 1. unable to override 2.x local home jndi name. In jboss.xml (jboss_5_0.dtd), the local home jndi is NOT allowed, so you have to refer to the default local home jndi -- beanName/local 2. when calling method on remote business interface, it works, but EJB exception is thrown by javax.ejb.EJBLocalObject.isIdentical. -- 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

14 years, 3 months

3
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2010