January 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JGRP-253) List officially supported classes/API for JGroups

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-253?page=com.atlassian.jira.plugi... ] Bela Ban updated JGRP-253: -------------------------- Fix Version/s: 2.10 (was: 2.9) > List officially supported classes/API for JGroups > ------------------------------------------------- > > Key: JGRP-253 > URL: https://jira.jboss.org/jira/browse/JGRP-253 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Vladimir Blagojevic > Priority: Minor > Fix For: 2.10 > > > List of APIs which are supported by JBoss, e.g. DistributedHashtable won't be supported -- 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

16 years, 6 months

1
0
0 / 0

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

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-1038?page=com.atlassian.jira.plug... ] Bela Ban updated JGRP-1038: --------------------------- Fix Version/s: 2.10 (was: 2.9) > FC2 > --- > > Key: JGRP-1038 > URL: https://jira.jboss.org/jira/browse/JGRP-1038 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.10 > > 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/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JGRP-100) Large-scale JGroups

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-100?page=com.atlassian.jira.plugi... ] Bela Ban updated JGRP-100: -------------------------- Fix Version/s: 2.10 (was: 2.9) > Large-scale JGroups > ------------------- > > Key: JGRP-100 > URL: https://jira.jboss.org/jira/browse/JGRP-100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.10 > > > - Run JGroups on hundreds of nodes (either physical, or simulation). > - Determine a protocol stack that can be used for large-scale execution > - Example: > - Coordinator may be SPOF. If coord is hung, messages will be sent, but no new views will > be generated > - Retransmission: retransmit from anyone (not sender, otherwise we have NAK implosion) > - Look at PBCAST -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JGRP-1037) Ergonomics: size thread pools dynamically

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-1037?page=com.atlassian.jira.plug... ] Bela Ban updated JGRP-1037: --------------------------- Fix Version/s: 2.10 (was: 2.9) > Ergonomics: size thread pools dynamically > ----------------------------------------- > > Key: JGRP-1037 > URL: https://jira.jboss.org/jira/browse/JGRP-1037 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.10 > > > Ergonomics are a step towards less configuration and more dynamic setting of values. Example: a thread pool's min and max sizes can be dynamically changed, based on observations. When we have a min size of 10, but the thread pool is always 75, then we should set the min size to 75 and possibly change the idle time too. > This is just a first step towards ergonomics and needs to be expanded on in 3.x releases -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-1123) GroupRequest: provide equivalent class to invoke unicast RPCs

by Bela Ban (JIRA)

GroupRequest: provide equivalent class to invoke unicast RPCs ------------------------------------------------------------- Key: JGRP-1123 URL: https://jira.jboss.org/jira/browse/JGRP-1123 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 Currently, GroupRequest is optimized towards invoking group RPCs. If we invoke an RPC on a single destination (versus a group), we incure overhead. For example, the target destination is wrapped into a list, and we acquire locks to modify the target list on SUSPECT and VIEW_CHANGE events. Goal: to create a SingleDestinationRequest, which has only 1 target destination address. For unicast RPCs, this should be much more efficient -- 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

16 years, 6 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBAS-3131) Extension-List MANIFEST attribute not honored during deployment of an EAR

by Dimitris Andreadis (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-3131?page=com.atlassian.jira.plug... ] Dimitris Andreadis updated JBAS-3131: ------------------------------------- Assignee: (was: Vicky Kak) > Extension-List MANIFEST attribute not honored during deployment of an EAR > ------------------------------------------------------------------------- > > Key: JBAS-3131 > URL: https://jira.jboss.org/jira/browse/JBAS-3131 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Deployers > Affects Versions: JBossAS-4.0.3 SP1 > Environment: Windows XP SP2, JDK 1.5.0_06 > Reporter: Alexander Sack > Priority: Minor > Fix For: JBossAS-6.0.0.M3 > > > If a JAR within an EAR specifies an Extension-List MANIFEST attribute, the EAR deployer does not honor it. I have a library, my.jar, that gets deployed that specifies an Extension-Name and Implementation-Version. If any of my jars within an EAR references this library, JBoss ignores the Extension-List attribute. The use of the Extension-List MANIFEST attribute is part of the core J2EE 1.4 spec and the EAR deployment should fail if the Extension-List library is not found (or if it is found and the <name>-Implementatino-Version does not meet the minimal requirements. -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2407) Handle declarations and collect metadatas and fields

by Toni Rikkola (JIRA)

Handle declarations and collect metadatas and fields ---------------------------------------------------- Key: JBRULES-2407 URL: https://jira.jboss.org/jira/browse/JBRULES-2407 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-verifier Reporter: Toni Rikkola Assignee: Toni Rikkola Fix For: 5.1.0.M2 -- 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

16 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2405) Fact model can be passed to verifier as a jar for additional information.

by Toni Rikkola (JIRA)

Fact model can be passed to verifier as a jar for additional information. ------------------------------------------------------------------------- Key: JBRULES-2405 URL: https://jira.jboss.org/jira/browse/JBRULES-2405 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 5.1.0.M2 Reporter: Toni Rikkola Assignee: Toni Rikkola Easier to know the types that the fields actually are, right now based on conclusions. -- 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

16 years, 6 months

1
4
0 / 0

[JBoss JIRA] Assigned: (GPD-374) It is not possible to define variable mapping in jBPM process editor Created: 08/Jan/08 04:26 AM Updated: 10/Mar/09 05:41 AM

by Tom Baeyens (JIRA)

[ https://jira.jboss.org/jira/browse/GPD-374?page=com.atlassian.jira.plugin... ] Tom Baeyens reassigned GPD-374: ------------------------------- Assignee: (was: Tom Baeyens) > It is not possible to define variable mapping in jBPM process editor Created: 08/Jan/08 04:26 AM Updated: 10/Mar/09 05:41 AM > ------------------------------------------------------------------------------------------------------------------------------- > > Key: GPD-374 > URL: https://jira.jboss.org/jira/browse/GPD-374 > Project: jBPM GPD > Issue Type: Feature Request > Components: jpdl > Environment: Environment: FC7/Eclipse Europa/jPDL Designer 3.1.0.SP1 > Reporter: Trevor Kirby > Fix For: jBPM jPDL Designer 3.2 > > > It is not possible to edit XML content of bpmToEsbVars and esbToBpmVars elements. > This now requires to edit process definition twice - once in graphical designer and second time in text editor to define mapping. This is very inconveniet for user as he frequently lose process arrangement as it is rearranged after this modification. > 1) I do not know if the jPDL designer supports editation of nested XML element > 2) If he supports it then we should find out if this is problem of only one platform or general deficiency -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMX-17) Release JBoss 6.0.0.Beta4

by Adrian Brock (JIRA)

Release JBoss 6.0.0.Beta4 ------------------------- Key: JBMX-17 URL: https://jira.jboss.org/jira/browse/JBMX-17 Project: JBossMX Issue Type: Task Components: release Reporter: Adrian Brock Assignee: Adrian Brock Fix For: JBossMX.6.0.0.Beta4 -- 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

16 years, 6 months

1
1
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 January 2010