[JBoss JIRA] (JGRP-1548) UNICAST2: send STABLE message after 'last received' message
by Bela Ban (JIRA)
Bela Ban created JGRP-1548:
------------------------------
Summary: UNICAST2: send STABLE message after 'last received' message
Key: JGRP-1548
URL: https://issues.jboss.org/browse/JGRP-1548
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
Contrary to UNICAST, which acks every message, UNICAST2 never acks messages, but only asks the sender to retransmit a message when a gap has been detected.
However, the drawback of this (negative ack) mechanism is the so called last-message-dropped problem: when A sends messages [1..5] to B, but 5 is dropped by the transport, as A doesn't retransmit messages until it gets an ack, B only gets messages [1..4].
B will *not* ask A to retransmit message 5, as B doesn't know A *sent* message 5 in the first place.
If A doesn't send message 6 for B to detect 5 is missing and asking A for retransmission, B won't get that message.
The way this is currently handled is with stable messages. A STABLE message is sent from B to A every stable_interval ms or whenever M bytes from A have been received. In the worst case, B will have to wait stable_interval ms until it finally receives message 5 from A.
SOLUTION:
In addition to time and size based STABLE messages, we could send a STABLE message whenever the batch of messages removed from the receive window has completed and the receive window is empty.
This would send a STABLE message immediately when a single message has been received (and no other messages from A are in the receive window), but it would only send another STABLE message only when all (e.g.) 200 messages from A have been processed and the receive window is empty.
With this new mechanism, we could even remove the time-based STABLE messages !
Example:
- At time T0, messages M1 and M2 are received. A STABLE message for M2 is sent.
- At T+500 (ms), messages M3-M100 are received. A STABLE message for M100 is sent
- At T+1500, M101 is received. A STABLE message for M101 is sent.
- At T+2000, M102 is received. A STABLE message for M102 is sent.
- At T+2010, M103-M500 are received. A STABLE message form M500 is sent
This is similar to the ACK based scheme in UNICAST where we only send an ack for the last message in a batch (or for a single message if not batch has been received).
This new mechanism needs to be configurable: if enabled, the time-based STABLE mechanism would be disabled.
If the
--
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-6082) EJbLogger contains messages that should be in EjbMessages
by Stuart Douglas (JIRA)
Stuart Douglas created AS7-6082:
-----------------------------------
Summary: EJbLogger contains messages that should be in EjbMessages
Key: AS7-6082
URL: https://issues.jboss.org/browse/AS7-6082
Project: Application Server 7
Issue Type: Bug
Components: EJB
Reporter: Stuart Douglas
Assignee: jaikiran pai
Priority: Minor
The EjbLogger class also contains exception messages, not just log messages.
It also has two loggers (ROOT_LOGGER and EJB3_LOGGER) with the same package name, it would be good to get rid of one of them.
--
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-6081) Provide a management operation to discover servers in a server group in domain mode
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created AS7-6081:
----------------------------------------
Summary: Provide a management operation to discover servers in a server group in domain mode
Key: AS7-6081
URL: https://issues.jboss.org/browse/AS7-6081
Project: Application Server 7
Issue Type: Feature Request
Components: CLI, Domain Management
Affects Versions: 7.1.3.Final (EAP)
Reporter: Richard Achmatowicz
Assignee: Alexey Loubyansky
Priority: Minor
Fix For: 7.2.0.Alpha1
In domain mode, an end user might want to start one or more servers by hand in a named server group. Obtaining the list of servers in a server group is not readily available: the "group" attribute is embedded in server-config, so we have to drill down into every /host=*/server-config=* combination to find out which servers belong to a specific server group.
It would improve the user experience to have an operation which shows which servers are in a given server group.
--
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] (LOGTOOL-62) Log filtering tool
by Jesper Pedersen (JIRA)
Jesper Pedersen created LOGTOOL-62:
--------------------------------------
Summary: Log filtering tool
Key: LOGTOOL-62
URL: https://issues.jboss.org/browse/LOGTOOL-62
Project: Log Tool
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Jesper Pedersen
Assignee: James Perkins
It would be nice to have a log filtering tool, which can help to extract / highlight log statements in huge log files.
An idea could be to have a SQL like language in order to limit the number of lines as much as possible
{noformat}
SELECT * FROM server.log WHERE CATEGORY = 'org.jboss.as' AND SEVERITY IN {FATAL OR ERROR OR WARN} AND TIMESTAMP >= '12:42:00,000' AND CONTENT CONTAINS 'Something went wrong'
{noformat}
Having functions to select all / a defined number of lines after each hit, between timestamps, and so on would be good.
--
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-5321) support expressions for remote-destination-outbound-socket-binding host attrib
by John Mazzitelli (JIRA)
John Mazzitelli created AS7-5321:
------------------------------------
Summary: support expressions for remote-destination-outbound-socket-binding host attrib
Key: AS7-5321
URL: https://issues.jboss.org/browse/AS7-5321
Project: Application Server 7
Issue Type: Feature Request
Affects Versions: 7.1.1.Final
Reporter: John Mazzitelli
I appears that remote-destination-outbound-socket-binding resources cannot have attributes that are expressions - at least the host attrtibute. In JBossAS 4.2.3, we used to have a stock email service.xml that people could customize by simply passing in new system properties (rather than editing .xml or going through a CLI to change the values). However, in AS 7.1.1.Final, we can't do this for the mail service because at least the host attribute does not appear to allow for expressions:
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=mail-smtp
My host attribute was set to the expression ${rhq.server.email.smtp-host:localhost} and when I tried to start the server, I got:
Caused by: java.net.UnknownHostException: ${rhq.server.email.smtp-host:localhost}
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method) [rt.jar:1.6.0_29]
at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:849) [rt.jar:1.6.0_29]
at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1202) [rt.jar:1.6.0_29]
at java.net.InetAddress.getAllByName0(InetAddress.java:1153) [rt.jar:1.6.0_29]
at java.net.InetAddress.getAllByName(InetAddress.java:1083) [rt.jar:1.6.0_29]
at java.net.InetAddress.getAllByName(InetAddress.java:1019) [rt.jar:1.6.0_29]
at java.net.InetAddress.getByName(InetAddress.java:969) [rt.jar:1.6.0_29]
at org.jboss.as.network.OutboundSocketBinding.getDestinationAddress(OutboundSocketBinding.java:146)
at org.jboss.as.mail.extension.MailSessionService.getServerSocketAddress(MailSessionService.java:106)
The weird thing is, the port attribute appears to allow for expressions. When my port is set to this expression: "${rhq.server.email.smtp-port:25}", the server starts up fine (that is, after I set to the host to a legitimate hostname like "localhost")
This JIRA is to request that expressions be supported for the host attribute as it appears to be supported for the port attribute.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5342) SAR MBean String attributes cannot be longer than about 3650 characters
by John Mazzitelli (JIRA)
John Mazzitelli created AS7-5342:
------------------------------------
Summary: SAR MBean String attributes cannot be longer than about 3650 characters
Key: AS7-5342
URL: https://issues.jboss.org/browse/AS7-5342
Project: Application Server 7
Issue Type: Feature Request
Affects Versions: 7.1.1.Final
Reporter: John Mazzitelli
I have a SAR. One of the MBean attributes is a String (actually, for my real use-case the value is a Properties object, but due to JIRA AS7-5336, there are other problems, but let's just go with String attribute type, because the same problem I will describe happens with that type, too)
If the string value is longer than around 3650 characters the beginning of the string is stripped (I can't nail it down to a specific value, but its around that number, give or take 10 characters or so)
For example, if I have this in jboss-service.xml:
<attribute name="MyStrAttrib">
This is a really long string.
...[lots of characters here]...
It has more than 3650
characters in it.
</attribute>
What my MBean setter (setMyStrAttrib(String s)) will be passed is something like "aracters in it." The characters at index 0 through ~3650 are missing, I only have the parts after it.
In my real example, the reason why the string is so long is that its a Properties string with lots of name/value pairs. I ended up working around AS7-5336 but then I hit this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6080) EJB 2.1 CMP configuration options missing
by Brad Maxwell (JIRA)
Brad Maxwell created AS7-6080:
---------------------------------
Summary: EJB 2.1 CMP configuration options missing
Key: AS7-6080
URL: https://issues.jboss.org/browse/AS7-6080
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.0.Alpha1, 7.1.3.Final (EAP)
Reporter: Brad Maxwell
Assignee: Stuart Douglas
Fix For: Open To Community
In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss.
Should also confirm how to configure the rest of the options that were available previously.
<container-configuration>
<container-name>Clustered CMP 2.x EntityBean</container-name>
<call-logging>false</call-logging>
<invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name>
<sync-on-commit-only>false</sync-on-commit-only>
<insert-after-ejb-post-create>false</insert-after-ejb-post-create>
<container-interceptors>
...
</container-interceptors>
<instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
<instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
<persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
<locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
<container-cache-conf>
<cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
<cache-policy-conf>
<min-capacity>50</min-capacity>
<max-capacity>1000000</max-capacity>
<overager-period>300</overager-period>
<max-bean-age>600</max-bean-age>
<resizer-period>400</resizer-period>
<max-cache-miss-period>60</max-cache-miss-period>
<min-cache-miss-period>1</min-cache-miss-period>
<cache-load-factor>0.75</cache-load-factor>
</cache-policy-conf>
</container-cache-conf>
<container-pool-conf>
<MaximumSize>100</MaximumSize>
</container-pool-conf>
<commit-option>B</commit-option>
</container-configuration>
--
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-6079) EJB 2.1 CMP configuration options missing
by Brad Maxwell (JIRA)
Brad Maxwell created AS7-6079:
---------------------------------
Summary: EJB 2.1 CMP configuration options missing
Key: AS7-6079
URL: https://issues.jboss.org/browse/AS7-6079
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.3.Final (EAP), 7.1.0.Alpha1
Reporter: Brad Maxwell
Assignee: Stuart Douglas
Fix For: Open To Community
In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss.
Should also confirm how to configure the rest of the options that were available previously.
<container-configuration>
<container-name>Clustered CMP 2.x EntityBean</container-name>
<call-logging>false</call-logging>
<invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name>
<sync-on-commit-only>false</sync-on-commit-only>
<insert-after-ejb-post-create>false</insert-after-ejb-post-create>
<container-interceptors>
...
</container-interceptors>
<instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
<instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
<persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
<locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
<container-cache-conf>
<cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
<cache-policy-conf>
<min-capacity>50</min-capacity>
<max-capacity>1000000</max-capacity>
<overager-period>300</overager-period>
<max-bean-age>600</max-bean-age>
<resizer-period>400</resizer-period>
<max-cache-miss-period>60</max-cache-miss-period>
<min-cache-miss-period>1</min-cache-miss-period>
<cache-load-factor>0.75</cache-load-factor>
</cache-policy-conf>
</container-cache-conf>
<container-pool-conf>
<MaximumSize>100</MaximumSize>
</container-pool-conf>
<commit-option>B</commit-option>
</container-configuration>
--
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