[JBoss JIRA] (JGRP-1868) Size of XMIT_REQ is not limited
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1868?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1868 at 9/16/14 8:14 AM:
---------------------------------------------------------
To prevent having to use a second {{FRAG}}, we could
* Send multiple XMIT-REQs, whose SeqnoList arg is size-limited to 60K (if transport == UDP). {{SeqnoList.size()}} computes the exact size.
* Send an XMIT-REQ only for the oldest N seqnos (as mentioned by Radim)
* (Re-)implement retransmission backoffs to reduce xmit traffic. However, this requires additional state in the xmit tables
* Compress SeqnoList to use less space, e.g. by using bitmaps/sets
was (Author: belaban):
To prevent having to use a second {{FRAG}}, we could
* Send multiple XMIT-REQs, whose SeqnoList arg is size-limited to 60K (if transport == UDP). {{SeqnoList.size()}} computes the exact size.
* Send am XMIT-REQ only for the oldest N seqnos (as mentioned by Radim)
* (Re-)implement retransmission backoffs to reduce xmit traffic. However, this requires additional state in the xmit tables
* Compress SeqnoList to use less space, e.g. by using bitmaps/sets
> Size of XMIT_REQ is not limited
> -------------------------------
>
> Key: JGRP-1868
> URL: https://issues.jboss.org/browse/JGRP-1868
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.4, 3.5
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> When UNICAST3 or NAKACK2 send XMIT_REQs, they serializes SeqnoList as payload without any limits upon its size. If there are too many missing messages, the XMIT_REQ grows over TP.max_bundle_size and cannot be sent at all.
> {code}
> JGRP000029: edg-perf03-10774: failed sending message to edg-perf01-63702 (64072 bytes): java.lang.Exception: message size (64072) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: UNICAST3: XMIT_REQ, seqno=0, UDP: [channel_name=default]
> {code}
> It's also undesirable to resend thousands of messages, as the receiver likely cannot process them all at once and only few of them will be actually processed. Therefore only X oldest ones (in order to cleanup the tables) should be resent.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1868) Size of XMIT_REQ is not limited
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1868?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1868 at 9/16/14 8:14 AM:
---------------------------------------------------------
To prevent having to use a second {{FRAG}}, we could
* Send multiple XMIT-REQs, whose SeqnoList arg is size-limited to 60K (if transport == UDP). {{SeqnoList.size()}} computes the exact size.
* Send am XMIT-REQ only for the oldest N seqnos (as mentioned by Radim)
* (Re-)implement retransmission backoffs to reduce xmit traffic. However, this requires additional state in the xmit tables
* Compress SeqnoList to use less space, e.g. by using bitmaps/sets
was (Author: belaban):
To prevent having to use a seond {{FRAG}}, we could
* Send multiple XMIT-REQs, whose SeqnoList arg is size-limited to 60K (if transport == UDP). {{SeqnoList.size()}} computes the exact size.
* Send am XMIT-REQ only for the oldest N seqnos (as mentioned by Radim)
* (Re-)implement retransmission backoffs to reduce xmit traffic. However, this requires additional state in the xmit tables
* Compress SeqnoList to use less space, e.g. by using bitmaps/sets
> Size of XMIT_REQ is not limited
> -------------------------------
>
> Key: JGRP-1868
> URL: https://issues.jboss.org/browse/JGRP-1868
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.4, 3.5
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> When UNICAST3 or NAKACK2 send XMIT_REQs, they serializes SeqnoList as payload without any limits upon its size. If there are too many missing messages, the XMIT_REQ grows over TP.max_bundle_size and cannot be sent at all.
> {code}
> JGRP000029: edg-perf03-10774: failed sending message to edg-perf01-63702 (64072 bytes): java.lang.Exception: message size (64072) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: UNICAST3: XMIT_REQ, seqno=0, UDP: [channel_name=default]
> {code}
> It's also undesirable to resend thousands of messages, as the receiver likely cannot process them all at once and only few of them will be actually processed. Therefore only X oldest ones (in order to cleanup the tables) should be resent.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1878.
----------------------------
Resolution: Won't Fix
The solution is to use {{bind_interfaces}} or {{bind_to_all_interfaces}}. Please re-open if you think there's a code change needed. Perhaps you want to add this to a case base somewhere...
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 3.2.14, 3.6
>
> Attachments: mcast.java
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1882) Possible NullPointerException in JDBC_PING
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1882?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1882.
----------------------------
Resolution: Done
> Possible NullPointerException in JDBC_PING
> ------------------------------------------
>
> Key: JGRP-1882
> URL: https://issues.jboss.org/browse/JGRP-1882
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Windows Server 2012
> Reporter: Thomas Santosa
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> JGroups version: 3.5.0 final
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.jgroups.protocols.JDBC_PING.readAll(Katalis.java:225)
> at org.jgroups.protocols.JDBC_PING.readAll(Katalis.java:192)
> at org.jgroups.protocols.JDBC_PING.findMembers(Katalis.java:128)
> at org.jgroups.protocols.Discovery.findMembers(Katalis.java:226)
> at org.jgroups.protocols.Discovery.down(Katalis.java:366)
> at org.jgroups.protocols.JDBC_PING.down(Katalis.java:124)
> at org.jgroups.protocols.MERGE2.down(Katalis.java:222)
> at org.jgroups.protocols.FD_SOCK.down(Katalis.java:356)
> at org.jgroups.protocols.FD_ALL.down(Katalis.java:233)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(Katalis.java:92)
> at org.jgroups.protocols.pbcast.NAKACK2.down(Katalis.java:551)
> at org.jgroups.protocols.UNICAST2.down(Katalis.java:584)
> at org.jgroups.protocols.pbcast.STABLE.down(Katalis.java:347)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(Katalis.java:76)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(Katalis.java:41)
> at org.jgroups.protocols.pbcast.GMS.down(Katalis.java:1084)
> at org.jgroups.protocols.FlowControl.down(Katalis.java:349)
> at org.jgroups.protocols.FlowControl.down(Katalis.java:349)
> at org.jgroups.protocols.FRAG2.down(Katalis.java:136)
> at org.jgroups.protocols.RSVP.down(Katalis.java:145)
> at org.jgroups.stack.ProtocolStack.down(Katalis.java:1039)
> at org.jgroups.JChannel.down(Katalis.java:785)
> at org.jgroups.JChannel._connect(Katalis.java:558)
> ... 40 more
> {noformat}
> I suspect that data is null. The code in line 225 is
> {code}
> if(local_addr != null && !local_addr.equals(data.getAddress()))
> addDiscoveryResponseToCaches(data.getAddress(), data.getLogicalName(), data.getPhysicalAddr());
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-573) Kie Server: bugs and enhancements
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-573?page=com.atlassian.jira.plugin... ]
Petr Široký commented on DROOLS-573:
------------------------------------
Currently there is now way to create stateless KieSession, server will always call newKieSession() no matter what is defined in kmodule.xml. As discussed over e-mail, this is bug and Edson is planning to fix it. Commenting here just to be sure it does not get forgotten.
> Kie Server: bugs and enhancements
> ---------------------------------
>
> Key: DROOLS-573
> URL: https://issues.jboss.org/browse/DROOLS-573
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.Beta1
> Reporter: Petr Široký
> Assignee: Edson Tirelli
>
> As discussed with Edson, I am creating list of possible bugs and enhancements for the KIE Server.
> Bugs:
> * Server returns NPE when the request body is empty (and is required). This happens for example when creating new container using /container/{id}, but not providing any data within the body (the XML/JSON specifying release-id, etc).
> * The server returns 201 (Created) even when the container was not actually created. Easy reproducer: try to create container using non-existing kjar GAV. The response code will be 201 and the response will be failure with message "Failed to create container 1...."
> Enhancements:
> * I think it it would useful to move the KieServer interface into -api module so that user's can use e.g. RestEasy ClientProxy to create own REST client in case the don't want to use the provided client.
> * When deplying the WAR into EAP 6.3.0 warning is dispalyed: JBAS016012: Deployment deployment "kie-server.war" contains CDI annotations but beans.xml was not found. The WAR file should contain beans.xml.
> The description will be updated if I found more such bugs/enhancements.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1879) log4j 2 suport error
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1879?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1879.
----------------------------
Resolution: Rejected
> log4j 2 suport error
> ---------------------
>
> Key: JGRP-1879
> URL: https://issues.jboss.org/browse/JGRP-1879
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.4, 3.5
> Environment: jdk 7
> Reporter: ming yue
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> LogFactory suport jdk log,log4j,log4j 2,but useing code like this:
> USE_JDK_LOGGER=isPropertySet(Global.USE_JDK_LOGGER);
> IS_LOG4J_AVAILABLE=isAvailable("org.apache.log4j.Logger");
> IS_LOG4J2_AVAILABLE=isAvailable("org.apache.logging.log4j.core.Logger");
> initialize var flag,
> the isAvailable function depend on ClassNotFoundException ,when useing log4j 2 Log4j 1.x bridge, has org.apache.log4j.Logger class ,then exception is not ClassNotFoundException ,change isAvailable cunction to:
> protected static boolean isAvailable(String classname) {
> try {
> return Class.forName(classname) != null;
> }
> catch(Exception cnfe) {
> return false;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3429) Classloader leak in JBossCachedAuthenticationManager
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3429?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3429:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1103735|https://bugzilla.redhat.com/show_bug.cgi?id=1103735] from NEW to MODIFIED
> Classloader leak in JBossCachedAuthenticationManager
> ----------------------------------------------------
>
> Key: WFLY-3429
> URL: https://issues.jboss.org/browse/WFLY-3429
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Josef Cacek
> Assignee: Emmanuel Hugonnet
> Priority: Critical
>
> When using a security domain with {{cache-type="default"}}, then the ModuleClassLoader instances related to deployments leak through JBossCachedAuthenticationManager.
> The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment).
> One option to solve this issue could be to remove the cache entries which are related to the undeployed application.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1879) log4j 2 suport error
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1879?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1879:
--------------------------------
Not sure I understand. JGroups uses log4j2 2.0, and class {{org.apache.log4j.Logger}} is not shipped with either the core or bridge lib.
> log4j 2 suport error
> ---------------------
>
> Key: JGRP-1879
> URL: https://issues.jboss.org/browse/JGRP-1879
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.4, 3.5
> Environment: jdk 7
> Reporter: ming yue
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> LogFactory suport jdk log,log4j,log4j 2,but useing code like this:
> USE_JDK_LOGGER=isPropertySet(Global.USE_JDK_LOGGER);
> IS_LOG4J_AVAILABLE=isAvailable("org.apache.log4j.Logger");
> IS_LOG4J2_AVAILABLE=isAvailable("org.apache.logging.log4j.core.Logger");
> initialize var flag,
> the isAvailable function depend on ClassNotFoundException ,when useing log4j 2 Log4j 1.x bridge, has org.apache.log4j.Logger class ,then exception is not ClassNotFoundException ,change isAvailable cunction to:
> protected static boolean isAvailable(String classname) {
> try {
> return Class.forName(classname) != null;
> }
> catch(Exception cnfe) {
> return false;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3846) JMS resources allows duplicate JNDI entries
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3846?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3846:
-----------------------------------------------
Jeff Mesnil <jmesnil(a)redhat.com> changed the Status of [bug 1140537|https://bugzilla.redhat.com/show_bug.cgi?id=1140537] from NEW to POST
> JMS resources allows duplicate JNDI entries
> -------------------------------------------
>
> Key: WFLY-3846
> URL: https://issues.jboss.org/browse/WFLY-3846
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.1.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> The JMS resources that can be stored in JNDI (connection-factory, pooled-connection-factory, jms-queue, jms-topic) does not check whether their list of JNDI entries contains duplicates.
> At runtime, duplicates are eliminated but this introduces a difference between the resource model with duplicate entries and its runtime state (without duplicates).
> The attribute definitions for their JNDI entries should validate at the MODEL stage that their value does not contain duplicate elements.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years