[JBoss JIRA] Created: (JBCACHE-1391) update documentation and FAQs
by Mircea Markus (JIRA)
update documentation and FAQs
-----------------------------
Key: JBCACHE-1391
URL: http://jira.jboss.com/jira/browse/JBCACHE-1391
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Mircea Markus
Assigned To: Manik Surtani
Fix For: 3.0.0.ALPHA1, 3.0.0.GA
Following should be updated in documentation:
1) document how the configuration will still accept old <mbean ... /> tags, but this is deprecated
2) document how the <mbean ... /> tag can cause problems with AS 5 (unintentional deployment), and how this can be done properly with the MC using the new <jbosscache ... /> tag
Notes:
Currently the XMLConfigurationParser looks for a <mbean ../> element, under which it pulls out more specific JBoss Cache elements.
This could easily change so the parser to accept this, or on failing to do so, to pick up a <jbosscache ... /> container element. And log a deprecation warning when using the old <mbean ... /> container tag.
--
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
18 years
[JBoss JIRA] Created: (JGRP-511) FC: dynamically adjust credits
by Bela Ban (JIRA)
FC: dynamically adjust credits
------------------------------
Key: JGRP-511
URL: http://jira.jboss.com/jira/browse/JGRP-511
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
FC currently has a static number of credits (max_credits). It would be beneficial to implement something similar to TCP's exponential backoff and slow start, to take the message loss rate into account.
Goal: when there is an overload, we reduce the credits in order to avoid compounding the overload by sending messages. On the other hand, we can send more messages when the receiver(s) have free capacity. To do this, each receiver sends the number of credits it can accept with its responses. By default, this would be the default number of credits (in TCP: size of the sliding window).
DESIGN:
NAKACK (and/or UNICAST) send the loss rate (rolling average of number of messages missing over number of messages received, per sender) when it exceeds a certain value (defined in NAKACK,UNICAST) up the stack.
FC looks at the loss rate and slices the number of credits for that sender in half (exponential backoff). On the next response, it piggy backs the new number of credits, so that sender will block sending messages.
When the loss rate drops below a certain (predefined) value, NAKACK sends another event up the stack. FC then increases the credits by a predefined value (slow start). Next time, it increases the value by the predefined value by 2 and so on, until the max number of credits have been reached again.
--
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
18 years