[JBoss JIRA] (JGRP-1507) MFC2: multicast flow control
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1507?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1507:
---------------------------
Fix Version/s: 3.4
(was: 3.3)
> MFC2: multicast flow control
> ----------------------------
>
> Key: JGRP-1507
> URL: https://issues.jboss.org/browse/JGRP-1507
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: Design.pdf
>
>
> The current flow control protocol (MFC) is slowing things down when we have high traffic in multicast networks (UDP based stack), especially when ethernet flow control (802.3) is disabled.
> One reason is that the number of credits (similar to the window size in TCP) is static, and doesn't change. E.g. it doesn't increase when there's no loss and doesn't shrink when there is loss.
> (This will be addressed by a different JIRA later)
> Another reason is that sender credits are currently only used up when *sending* messages, but not when *receiving* messages. Thus, if we have 50MB of credits, a sender A can send 50MB until A blocks. However, when it receives 20MB of traffic from B while it sends the 50MB, it doesn't take the 20MBs into account.
> Therefore, a receiver S can be overwhelmed by receiving both A's and B's traffic (the switch might even start discarding messages before they reach S).
> The change from MFC to MFC2 is that a sender only maintains 1 'credits' counter (number of bytes): whenever it sends a message, it decrements credits. Whenever it receives traffic from someone else, it also decrements credits. When credits is 0, the sender blocks (asking for more credits). When credits drops below a certain threshold, it multicasts 1/N of the max credits (N = number of cluster members). (TBD: perhaps it should mcast a fixed number, independent of the cluster size).
> The advantage of this scheme is that a sender blocks sooner, and not when it's too late (congestion).
> Example:
> - credits = 100MB
> - Concurrently: A sends 50MB, B sends 30MB and C sends 60MB
> - At time T1, A has sent 20MB, and we've already received 10MB from B and 20 from C, credits is now 50MB
> - At time T2, A sent another 20MB, and received 20MB from C. credits is now 10MB, and A multicasts 35MB (rounded)
> - At T3, A receives another 10MB from B, credits=0
> - At T4, A blocks trying to send its remaining 10MBs, as credits = 0
> - At T5, A receives its 35MB of credits and sends its remaining 10MB, and also receives 20MB from C, and the remaining 10MB from B. credits is now -5 and A would block sending more credits
> - At T6, A multicasts 35MBs of credits
> - At T7, A receives 35MB of credits from B and C, credits= ca 65MB
> - At T8, A receives its own 35MBs of credits, credits=~100MB
--
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, 6 months
[JBoss JIRA] (JGRP-1544) FORWARD_TO_COORD is slow
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1544?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1544:
---------------------------
Fix Version/s: 3.4
(was: 3.3)
> FORWARD_TO_COORD is slow
> ------------------------
>
> Key: JGRP-1544
> URL: https://issues.jboss.org/browse/JGRP-1544
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> When doing xsite perf tests, JGRP-1542 fixed a perf issue by passing message flags on when forwarding / relaying a message. However, the biggest perf culprit was FORWARD_TO_COORD.
> This JIRA will investigate the cause (probably the forward-table and delivery-table handling) and hopefully fix it.
> Meanwhile, the recommendadtion is to comment FORWARD_TO_COORD.
--
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, 6 months
[JBoss JIRA] (JGRP-1550) 2.6.22.Final not running on 1.6 JVM
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1550?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1550:
--------------------------------
Is this JIRA still relevant ?
The JGroups component used by EAP 5 is built using Brew and pulling the sources from GitHub anyway, so no generated artifacts provided via SourceForge or Nexus are consumed.
I'll make sure next time I use JDK 6 when building and releasing artifacts.
> 2.6.22.Final not running on 1.6 JVM
> -----------------------------------
>
> Key: JGRP-1550
> URL: https://issues.jboss.org/browse/JGRP-1550
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.6.21
> Environment: JVM 1.6
> Reporter: MIchael Yates
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> 2.6.22 has been built using JDK 7
> #A dump from a 2.6.21 class
> hexdump -n20 ./org/jgroups/MembershipListener.class
> 0000000 ca fe ba be 00 00 00 32 00 0d 07 00 0b 07 00 0c
> #A dump from a 2.6.22 class
> hexdump -n20 ./org/jgroups/MembershipListener.class
> 0000000 ca fe ba be 00 00 00 33 00 0d 07 00 0b 07 00 0c
> Note the 8th octet has changed form 32 to 33. ie from JVM6 to JVM7
> I suspect this is an oversight when 2.6.22 was built. Maybe -source and -target parameters forgotten on the build?
--
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, 6 months
[JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/JASSIST-163?page=com.atlassian.jira.plugi... ]
Brett Meyer commented on JASSIST-163:
-------------------------------------
Lisa: https://hibernate.onjira.com/browse/HHH-7435
Hibernate 4.1.9 pulled in Javassist 3.17.1
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
> Key: JASSIST-163
> URL: https://issues.jboss.org/browse/JASSIST-163
> Project: Javassist
> Issue Type: Enhancement
> Affects Versions: 3.15.0-GA, 3.16.1-GA
> Environment: hibernate-core 3.6.10.Final
> Reporter: Nikita Tovstoles
> Assignee: Shigeru Chiba
> Fix For: 3.17.0-GA
>
> Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
> synchronized (methods) {
> if (methods[index] == null) {
> methods[index + 1] = thisMethod == null ? null
> : findMethod(self, thisMethod, desc);
> methods[index] = findSuperMethod(self, superMethod, desc);
> }
> }
> {code}
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately
--
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, 6 months
[JBoss JIRA] (AS7-6267) configurable row count for tables in console
by Marian Stránecký (JIRA)
Marian Stránecký created AS7-6267:
-------------------------------------
Summary: configurable row count for tables in console
Key: AS7-6267
URL: https://issues.jboss.org/browse/AS7-6267
Project: Application Server 7
Issue Type: Bug
Components: Console
Affects Versions: 7.2.0.Alpha1
Environment: any web browser
Reporter: Marian Stránecký
Assignee: Heiko Braun
Priority: Minor
Number of rows in tables is hardcoded to 8 ("... new DefaultCellTable<.....>(8);")
This can be considered to be a low value for large sets (e.g. imagine tens or thousands of bundles in OSGi subsystem).
The value should be configurable by the user (e.g. combobox with predefined values - 10, 25, 50, 100)
--
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, 6 months
[JBoss JIRA] (JGRP-1352) StreamingStateTransfer: queue requests during state transfer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1352?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1352:
---------------------------
Fix Version/s: 3.4
(was: 3.3)
> StreamingStateTransfer: queue requests during state transfer
> ------------------------------------------------------------
>
> Key: JGRP-1352
> URL: https://issues.jboss.org/browse/JGRP-1352
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> STATE should queue requests to be delivered to the application while a state transfer is in progress.
> Draft design:
> * MessageQueue: queue for application messages
> * STATE-REQ queue: queue for STATE-REQ requests
> * On STATE-REQ:
> ** If busy --> add request to STATE-REQ queue, return
> ** Else --> processRequest
> ** Close MessageQueue and deliver all messages in it to the application
> *** Regular message deliver needs to be blocked until all messages from the MessageQueue have been delivered
> ** Kick off a STABLE round, wait until it completes
> ** If STATE-REQ queue is not empty --> processRequests()
> * processRequest():
> ** Close BARRIER, suspend STABLE
> ** Get digest
> ** Open MessageQueue: all new messages (MSG) will be queued now, rather than delivered to the application
> *** (Only MSG, not VIEW !)
> ** Open BARRIER (leave STABLE suspended !)
> ** Transfer state to state requester
> ** Resume STABLE
> Advantages:
> - The state provider is not blocked, e.g. to handle JOIN requests
> - Only the state *requester* is blocked, this is OK though
> - Between the state requests, the state provider gets a little breathing room to process
> queued-up messages, and to purge messages (through stability)
> - Disadvantages:
> - If *blocking* messages (e.g. RPCs) are queued, we won't be able to send responses back until the queue is drained
> Misc:
> - Should the MessageQueue use the disk to handle large message sets ?
> - If modifications are idempotent, we *don't* need to queue messages (make this configurable !)
> (for example Infinispan ?)
--
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, 6 months
[JBoss JIRA] (JGRP-1506) RELAY2: hierarchical routing
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1506?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1506:
---------------------------
Fix Version/s: 3.4
(was: 3.3)
> RELAY2: hierarchical routing
> ----------------------------
>
> Key: JGRP-1506
> URL: https://issues.jboss.org/browse/JGRP-1506
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> Currently, RELAY2 only supports routing to sites which are directly accessible from the current site (by registering via a bridge and adding their entries to the routing table).
> Hierarchical routing should support sending messages to sites which are only indirectly connected. This could be done either via shorts for site-IDs, or via strings. Let's look at an example for strings:
> - We have sites us.nyc, us.sfo and us.lax. These site-IDs are added to every site master's routing table
> - In addition, we also define (in the US) an entry eu.* which has NYC as gateway. This means that our routing table (e.g. on the SiteMaster in SFO) looks as follows:
> - us.sfo: <local bridge>
> - us.nyc: <local bridge>
> - us.lax: <local bridge>
> - eu.*: <forward to us.nyc>
> So when we send a message to eu.south.spain in SFO, we'll match it component by component against each entry in the routing table. Since there is no direct match, we'll finally end up matching against the forqward route "eu.*" and thus send it to NYC.
> We could also use routing based on shorts (current solution), or even introduce inet addresses (e.g. 1.2.3.4).
> However, I currently favor strings as (1) they are always easily readable and (2) don't require the conversion table between strings and shorts. However, the downside is that they use more space. Not a big issue though as they're only used in relay messages (between sites) and not *within* a site.
> Hierarchical routing will require changes to the relay config XML file.
--
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, 6 months
[JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
by Lisa Henderson (JIRA)
[ https://issues.jboss.org/browse/JASSIST-163?page=com.atlassian.jira.plugi... ]
Lisa Henderson commented on JASSIST-163:
----------------------------------------
Scott,
Can you please clarify what product (Javassist or Hibernate?) and version the patch is against, and where it is available? With Javassist 3.17.0 and Hibernate 4.1.7, I am still seeing java.lang.VerifyError: Inconsistent stackmap frames exceptions.
Thanks for the clarification,
Lisa.
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
> Key: JASSIST-163
> URL: https://issues.jboss.org/browse/JASSIST-163
> Project: Javassist
> Issue Type: Enhancement
> Affects Versions: 3.15.0-GA, 3.16.1-GA
> Environment: hibernate-core 3.6.10.Final
> Reporter: Nikita Tovstoles
> Assignee: Shigeru Chiba
> Fix For: 3.17.0-GA
>
> Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
> synchronized (methods) {
> if (methods[index] == null) {
> methods[index + 1] = thisMethod == null ? null
> : findMethod(self, thisMethod, desc);
> methods[index] = findSuperMethod(self, superMethod, desc);
> }
> }
> {code}
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately
--
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, 6 months
