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 commented on JGRP-1038: -------------------------------- Looks like FC2 handles only *unicasts*, not multicasts. Is this what FC2's supposed to do ? If so, it could be an alternative to UFC... A good perf test would be UnicastTestRpcDist. > 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] Created: (SECURITY-519) EJBXACMLUtil should consider overloaded methods

by Anil Saldhana (JIRA)

EJBXACMLUtil should consider overloaded methods ----------------------------------------------- Key: SECURITY-519 URL: https://jira.jboss.org/browse/SECURITY-519 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Bug Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: PicketBox_v3_0_beta5 Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: PicketBox_v3_0_beta6 -- 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
3
0 / 0

[JBoss JIRA] Created: (JBAS-8247) Track EJB3 upgrades to AS trunk

by jaikiran pai (JIRA)

Track EJB3 upgrades to AS trunk ------------------------------- Key: JBAS-8247 URL: https://jira.jboss.org/browse/JBAS-8247 Project: JBoss Application Server Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Components: EJB3 Reporter: jaikiran pai Assignee: jaikiran pai Track EJB3 bom upgrades to AS trunk -- 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
2
0 / 0

[JBoss JIRA] Assigned: (JBAS-8276) Weld Extension vs. Tomcat deployer in JBoss 6

by Heiko Braun (JIRA)

[ https://jira.jboss.org/browse/JBAS-8276?page=com.atlassian.jira.plugin.sy... ] Heiko Braun reassigned JBAS-8276: --------------------------------- Assignee: Heiko Braun (was: Marius Bogoevici) > Weld Extension vs. Tomcat deployer in JBoss 6 > --------------------------------------------- > > Key: JBAS-8276 > URL: https://jira.jboss.org/browse/JBAS-8276 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Affects Versions: 6.0.0.M4 > Reporter: Heiko Braun > Assignee: Heiko Braun > > When I deploy a web application that contains CDI beans to JBoss6-M4 I can see that bean deployment being executed two times. First the CDI deployer kicks in, then Tomcat deployer re-deploys the war archive, which causes a second execution of the extension: > 12:20:34,082 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:34,516 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:34,564 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:34,583 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:34,720 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > 12:20:39,776 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] undeploy, ctxPath=/funky-app > 12:20:40,246 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:40,733 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:40,844 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:40,856 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:40,929 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > Shouldn't it be the execution the extension tight to the tomcat deployer lifecycle? I.e. be dependent on it's meta data? -- 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-8396) Don't set the NamingManager.InitialContextFactoryBuilder if already set in NamingSubsystemElement

by Kabir Khan (JIRA)

Don't set the NamingManager.InitialContextFactoryBuilder if already set in NamingSubsystemElement ------------------------------------------------------------------------------------------------- Key: JBAS-8396 URL: https://jira.jboss.org/browse/JBAS-8396 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Naming Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 7.0.0.M1 In unit tests we might need to reuse this, and with the jdk implementation MM.setICFB() throws an error if already set -- 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
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1861) Ruleflow diagram not proprly displayed

by Jaroslaw Kijanowski (JIRA)

Ruleflow diagram not proprly displayed -------------------------------------- Key: JBRULES-1861 URL: https://jira.jboss.org/jira/browse/JBRULES-1861 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.0.0.M3 Reporter: Jaroslaw Kijanowski Assignee: Michael Neale Attachments: expected.png, rf.png -- 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, 4 months

3
9
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2167) @TransactionAttribute declared in superclass is ignore & @TransactionAttribute conflict to Deployment Descriptor

by e t (JIRA)

@TransactionAttribute declared in superclass is ignore & @TransactionAttribute conflict to Deployment Descriptor ---------------------------------------------------------------------------------------------------------------- Key: EJBTHREE-2167 URL: https://jira.jboss.org/browse/EJBTHREE-2167 Project: EJB 3.0 Issue Type: Bug Components: ejb3 Environment: jboss-5.1.0.GA Sun jdk1.6.0_16 WinXP 32bit Reporter: e t Attachments: src.rar According to the EJB3 Specification，If the bean class has superclasses, the following additional rules apply. • A transaction attribute specified on a superclass S applies to the business methods defined by S. If a class-level transaction attribute is not specified on S, it is equivalent to specification of TransactionAttribute(REQUIRED) on S. • A transaction attribute may be specified on a business method M defined by class S to override for method M the transaction attribute value explicitly or implicitly specified on the class S. • If a method M of class S overrides a business method defined by a superclass of S, the transaction attribute of M is determined by the above rules as applied to class S. The issue is : 1 . When I take the test of a SLSB which has a superclass and its transaction attribute is set to NEVER, I always get the method call in transaction attribute is set to REQUIRED(see the follow code for details). 2 . When I deploy an empty ejb-jar.xml and jboss.xml to META-INF directory, the SLSB's transaction attribute is set to SUPPORTS/NOT_SUPPORTEDNEVER PS:I using the EntityManager's persist method call for checking current method call is associated with a transaction. -- 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, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (JBBUILD-647) Add maven-cli-plugin repository to proxy repositories

by Paul Gier (JIRA)

Add maven-cli-plugin repository to proxy repositories ----------------------------------------------------- Key: JBBUILD-647 URL: https://jira.jboss.org/browse/JBBUILD-647 Project: JBoss Build System Issue Type: Task Components: Artifact Repositories Reporter: Paul Gier Assignee: Paul Gier Priority: Minor Fix For: Repository Support 2010 It was requested to add a nexus proxy to the google repo which contains the maven-cli-plugin http://twdata-m2-repository.googlecode.com/svn -- 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, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-913) java.lang.IllegalStateException in SessionContext::getCallerPrincipal()

by Mihail Druzinin (JIRA)

java.lang.IllegalStateException in SessionContext::getCallerPrincipal() ----------------------------------------------------------------------- Key: EJBTHREE-913 URL: http://jira.jboss.com/jira/browse/EJBTHREE-913 Project: EJB 3.0 Issue Type: Bug Components: Security Affects Versions: EJB 3.0 RC9 - FD Environment: AS: jboss-4.0.5 (ejb3 Version EJB 3.0 RC7 - FD and EJB3 RC9 Patch 1) OS: Windows, GentooLinux Reporter: Mihail Druzinin >From HttpServlet I execute methods from stateless been. All methods executed correctly with authorization. When in method I try sessionContext.getCallerPrincipal(), then throws java.lang.IllegalStateException: No valid security context for the caller identity After see in jboss security module I find that in org.jboss.security.SecurityAssociation getCallerPrincipal() when used RunAsIdentity, it getted not from top of RunAsIdentity stack, but "for the active run-as the previous caller has assumed": Principal thePrincipal = peekRunAsIdentity(1); (SecurityAssociation.java:216). After fixed that string to: Principal thePrincipal = peekRunAsIdentity(0), all start work. -- 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, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1518) implement Singleton Session Beans

by Alexey Loubyansky (JIRA)

implement Singleton Session Beans --------------------------------- Key: EJBTHREE-1518 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1518 Project: EJB 3.0 Issue Type: Task Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Section 4.8 "Singleton Session Beans" of the EJB3.1 spec draft. -- 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, 4 months

3
2
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