January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1564) TP: message batches

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1564?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1564: --------------------------- Summary: TP: message batches (was: TP: handling of message batches) > TP: message batches > ------------------- > > Key: JGRP-1564 > URL: https://issues.jboss.org/browse/JGRP-1564 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages). > It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go. > The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions). > We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up. > The unmarshalling shouldn't take long, so TP.receive() should return quickly. > This approach would allow us to send OOB messages in message batches, too (currently not allowed). > The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal. > The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT, SIZE, FRAG(2) (if placed under UNICAST/NAKACK), COMPRESS etc. However, we could add another up(Batch) method, which by default (in Protocol): > - removes all messages for a given protocol P (by P.ID) > and calls up(Event.MSG, msg) for all messages in the batch > - calls up_prot.up(batch) if the batch is not empty > This would allow for all current protocols to continue working and only the protocols which don't check for headers and/or need special processing (such as UNICAST and NAKACK) would have to implement up(Batch). > This solution would be better than introducing another event type MSG_BATCH, as not every protocol overriding up(Event) calls super.up(Event). > However, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1570) STABLE: desired_avg_gossip leads to long intervals between reception of STABILITY messages in large clusters

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1570?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1570: -------------------------------- STABLE.max_bytes is also scaled with the cluster size; this may have to be changed, too. So if max_bytes is 400K, with 2 members it is 800K, with 10 members it is 4MB: this does change the time to send a STABILITY message, and to be in line with what was suggested above, we probably need to remove the scaling, too. > STABLE: desired_avg_gossip leads to long intervals between reception of STABILITY messages in large clusters > ------------------------------------------------------------------------------------------------------------ > > Key: JGRP-1570 > URL: https://issues.jboss.org/browse/JGRP-1570 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > The time computed for the sending of STABLE is desired_avg_gossip * cluster-size *2. While this is OK for small clusters, it may be too big for large clusters. > On the other hand, if every member simply multicasts a STABLE message every (say) 30 seconds on average, then the number of messages sent grows with increasing cluster size. > Investigate a way to set a lower and upper limit for the making and delivery of *STABILITY* messages, e.g. the goal is to receive 1 stability message every 60s. > Besides increased traffic, however, this requires everyone to have a TCP connection to everybody else in the cluster in case of a TCP transport. > A better solution might be to have only a dedicated member (the coord) periodically multicast a STABLE message. Everyone replies with a (unicast) STABLE message and when the coord has received STABLE replies from everyone, it multicasts a STABILITY message. This would only require a multicast from the coord to everyone, establishing TCP connections from the coord to everyone (usually already exists because of the VIEW-CHANGE multicast), but everyone would reuse the same TCP connection to send the reply. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6334) Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/AS7-6334?page=com.atlassian.jira.plugin.s... ] Jeff Mesnil updated AS7-6334: ----------------------------- Description: Task to track the work we've all been doing on expressions/transformers. See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem: 1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute. 2) Basic transformation testing against 7.1.2 and 7.1.3 3) Reject-expression testing against 7.1.2 and 7.1.3 Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something. Please edit this description and put an OK after the subsystem name to indicate it's good to go. clustering/jgroups (OK) clustering/infinispan cmp configadmin [OK] connector/datasource connector/jca [OK] connector/resource-adapter deployment-scanner ee ejb3 [OK] jacorb - Just a note: the 'security' attribute transformation is not tested jaxr OK jaxrs - nothing to do, empty subsystem jdr - nothing to do, empty subsystem jmx (OK) jpa (OK) jsf [PR https://github.com/jbossas/jboss-as/pull/3925] jsr77 - nothing to do, empty subsystem logging mail messaging [OK] modcluster naming [PR https://github.com/jbossas/jboss-as/pull/3910] osgi (OK) pojo - nothing to do, empty subsystem remoting - [OK] sar - nothing to do, empty subsystem security threads transactions (just needs AS7-6336) web webservices weld - nothing to do, empty subsystem xts - nothing to do, susbystem model has not changed since 7.1.2 & 7.1.3 was: Task to track the work we've all been doing on expressions/transformers. See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem: 1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute. 2) Basic transformation testing against 7.1.2 and 7.1.3 3) Reject-expression testing against 7.1.2 and 7.1.3 Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something. Please edit this description and put an OK after the subsystem name to indicate it's good to go. clustering/jgroups (OK) clustering/infinispan cmp configadmin [OK] connector/datasource connector/jca [OK] connector/resource-adapter deployment-scanner ee ejb3 [OK] jacorb - Just a note: the 'security' attribute transformation is not tested jaxr OK jaxrs - nothing to do, empty subsystem jdr - nothing to do, empty subsystem jmx (OK) jpa (OK) jsf [WIP JFM] jsr77 - nothing to do, empty subsystem logging mail messaging [OK] modcluster naming [PR https://github.com/jbossas/jboss-as/pull/3910] osgi (OK) pojo - nothing to do, empty subsystem remoting - [OK] sar - nothing to do, empty subsystem security threads transactions (just needs AS7-6336) web webservices weld - nothing to do, empty subsystem xts - nothing to do, susbystem model has not changed since 7.1.2 & 7.1.3 > Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems > -------------------------------------------------------------------------------------------------------------------------------- > > Key: AS7-6334 > URL: https://issues.jboss.org/browse/AS7-6334 > Project: Application Server 7 > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 7.2.0.Alpha1 > > > Task to track the work we've all been doing on expressions/transformers. > See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem: > 1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute. > 2) Basic transformation testing against 7.1.2 and 7.1.3 > 3) Reject-expression testing against 7.1.2 and 7.1.3 > Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something. > Please edit this description and put an OK after the subsystem name to indicate it's good to go. > clustering/jgroups (OK) > clustering/infinispan > cmp > configadmin [OK] > connector/datasource > connector/jca [OK] > connector/resource-adapter > deployment-scanner > ee > ejb3 [OK] > jacorb - Just a note: the 'security' attribute transformation is not tested > jaxr OK > jaxrs - nothing to do, empty subsystem > jdr - nothing to do, empty subsystem > jmx (OK) > jpa (OK) > jsf [PR https://github.com/jbossas/jboss-as/pull/3925] > jsr77 - nothing to do, empty subsystem > logging > mail > messaging [OK] > modcluster > naming [PR https://github.com/jbossas/jboss-as/pull/3910] > osgi (OK) > pojo - nothing to do, empty subsystem > remoting - [OK] > sar - nothing to do, empty subsystem > security > threads > transactions (just needs AS7-6336) > web > webservices > weld - nothing to do, empty subsystem > xts - nothing to do, susbystem model has not changed since 7.1.2 & 7.1.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-977) ActivationSpec's ConfigProperty, that have @NotNull annotation should be proceeded as <required-config-property>

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-977?page=com.atlassian.jira.plugin.... ] Jesper Pedersen updated JBJCA-977: ---------------------------------- Summary: ActivationSpec's ConfigProperty, that have @NotNull annotation should be proceeded as <required-config-property> (was: ActivationSpec's ConfigProperty, that have @NotNull annotation should be proceeded as <requiredConfigProperty>) Priority: Critical (was: Major) > ActivationSpec's ConfigProperty, that have @NotNull annotation should be proceeded as <required-config-property> > ---------------------------------------------------------------------------------------------------------------- > > Key: JBJCA-977 > URL: https://issues.jboss.org/browse/JBJCA-977 > Project: IronJacamar > Issue Type: Bug > Components: Common > Affects Versions: 1.0.15.Final, 1.1.0.Beta3 > Reporter: Vladimir Rastseluev > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.16.Final, 1.1.0.Beta4 > > > Resulting Connector, which have @NotNull annotation in ActivationSpec's ConfigProperty doesn't mark this property as "Required" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-978) Values of @SecurityPermission's description annotation don't propagate to the resulting Connector

by Vladimir Rastseluev (JIRA)

Vladimir Rastseluev created JBJCA-978: ----------------------------------------- Summary: Values of @SecurityPermission's description annotation don't propagate to the resulting Connector Key: JBJCA-978 URL: https://issues.jboss.org/browse/JBJCA-978 Project: IronJacamar Issue Type: Bug Reporter: Vladimir Rastseluev Assignee: Jesper Pedersen If we have Connector, containing annotation like this: @Connector( ... @SecurityPermission(description = {"description1",...}...) ) after annotation proceeding we don't get any <description> element in security-permission section. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-977) ActivationSpec's ConfigProperty, that have @NotNull annotation should be proceeded as <requiredConfigProperty>

by Vladimir Rastseluev (JIRA)

Vladimir Rastseluev created JBJCA-977: ----------------------------------------- Summary: ActivationSpec's ConfigProperty, that have @NotNull annotation should be proceeded as <requiredConfigProperty> Key: JBJCA-977 URL: https://issues.jboss.org/browse/JBJCA-977 Project: IronJacamar Issue Type: Bug Components: Common Affects Versions: 1.1.0.Beta3, 1.0.15.Final Reporter: Vladimir Rastseluev Assignee: Jesper Pedersen Fix For: 1.0.16.Final, 1.1.0.Beta4 Resulting Connector, which have @NotNull annotation in ActivationSpec's ConfigProperty doesn't mark this property as "Required" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-976) Wrong (annotated @Connector resourceadapter class + an empty Connector) merging result

by Vladimir Rastseluev (JIRA)

Vladimir Rastseluev created JBJCA-976: ----------------------------------------- Summary: Wrong (annotated @Connector resourceadapter class + an empty Connector) merging result Key: JBJCA-976 URL: https://issues.jboss.org/browse/JBJCA-976 Project: IronJacamar Issue Type: Bug Reporter: Vladimir Rastseluev Assignee: Jesper Pedersen Result of merging: 1) @Connector annotated resourceadapter Class; with 2) an empty Connector is a Connector without <resourceadapter-class> element -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-975) Wrong (@Connector transactionSupport level + an empty Connector) merging result

by Vladimir Rastseluev (JIRA)

Vladimir Rastseluev created JBJCA-975: ----------------------------------------- Summary: Wrong (@Connector transactionSupport level + an empty Connector) merging result Key: JBJCA-975 URL: https://issues.jboss.org/browse/JBJCA-975 Project: IronJacamar Issue Type: Bug Components: Common Affects Versions: 1.1.0.Beta3, 1.0.15.Final Reporter: Vladimir Rastseluev Assignee: Jesper Pedersen Fix For: 1.0.16.Final, 1.1.0.Beta4 Connector, that have any TransactionSupport.TransactionSupportLevel, set in @Connector annotation, after merging with an empty Connector always have resulting TransactionSupport.TransactionSupportLevel.NoTransactions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-974) Wrong proceeding of version element in @Connector annotations

by Vladimir Rastseluev (JIRA)

Vladimir Rastseluev created JBJCA-974: ----------------------------------------- Summary: Wrong proceeding of version element in @Connector annotations Key: JBJCA-974 URL: https://issues.jboss.org/browse/JBJCA-974 Project: IronJacamar Issue Type: Bug Components: Common Affects Versions: 1.1.0.Beta3, 1.0.15.Final Reporter: Vladimir Rastseluev Assignee: Jesper Pedersen Fix For: 1.0.16.Final, 1.1.0.Beta4 Proceeding of @Connector(version = "anyVersion") always leads to creation of "<resorceadapter-version>1.6</resourceadapter-version>" element. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-973) Wrong proceeding of Icon elements in @Connector annotations

by Vladimir Rastseluev (JIRA)

Vladimir Rastseluev created JBJCA-973: ----------------------------------------- Summary: Wrong proceeding of Icon elements in @Connector annotations Key: JBJCA-973 URL: https://issues.jboss.org/browse/JBJCA-973 Project: IronJacamar Issue Type: Bug Components: Common Affects Versions: 1.1.0.Beta3, 1.0.15.Final Reporter: Vladimir Rastseluev Assignee: Jesper Pedersen Fix For: 1.0.16.Final, 1.1.0.Beta4 JCA 1.6 specification, page 18-7: Each smallIcon must be associated with a largeIcon element and the application server must use the ordinal value in their respective arrays to find the related pairs of icons. Annotations proceeding of icon arrays doesn't lead to creation <icon> elements with related pairs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 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 January 2013