August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1873) UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1873?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1873: --------------------------- Fix Version/s: 3.5.1 3.6 (was: 3.5) > UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender > -------------------------------------------------------------------------------------- > > Key: JGRP-1873 > URL: https://issues.jboss.org/browse/JGRP-1873 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table. > Example: > * A sends messages to B > * A has an entry for B in its send-table: {{B: 10|20}} (lowest sent=10, highest sent=20) > * B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20) > * B now gets a view that doesn't contain A and closes its connection to A > ** This results in B's connection to A getting removed > * A now sends message {{A::21}} > * B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A > * A receives the request and sends message {{A::11 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that some of them are dropped. > * B does receive {{A::11 first}} and creates an entry for A in its recv-table: {{A: 11|21}} (next to be received is {{A:12}}) > * Now a spurious {{STABLE(A::15)}} message by B is received by A > ** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection > ** Note that the connection ID ({{conn-id}} is the same, so A will _not_ reject the {{STABLE}} message by B > * A receives the {{STABLE}} message and purges elements up to 15, so its new entry for B is: {{B:: 15|21}} > * When B asks A for retransmission of messages {{A::12}} - {{A:21}}, A can only retransmit messages 16-21, but *not* {{A::12}} - {{A:15}} ! > Depending on which messages from A (which it sent unreliably on reception of {{GET-FIRST-SEQNO}}) were received by B, there would be never-ending retransmission requests from B to A for all or some messages in {{A[12..15]}}, e.g. > {noformat} > WARN [org.jgroups.protocols.UNICAST2] A: (requester=B) message B::13 not found in > retransmission table of B: [15 | 15 | 22] (X elements, Y missing) > {noformat} > h5. Reordering of STABLE messages > In the worst case, as {{STABLE}} messages are not sent reliably and can therefore get dropped or reordered, if A gets another {{STABLE(10)}} message after the {{STABLE(15)}} message, the error message above would look like this: > {noformat} > WARN [org.jgroups.protocols.UNICAST2] A: (requester=B) message B::13 not found in > retransmission table of B: [10 | 10 | 22] (X elements, Y missing) > {noformat} > Note that, with https://issues.jboss.org/browse/JGRP-1872 fixed, this cannot occur anymore. > h5. Solution > There's no real solution but to upgrade to {{UNICAST3}}: when {{UNICAST3}} receives a view, it doesn't _remove_ receive (and send) connections immediately, but merely marks them as _closed_. The connection will only be removed after {{conn_close_timeout}} ms. If B therefore gets further messages from A, it will simply mark the receive connection as _open_ and doesn't need to send a {{GET-FIRST-SEQNO}} message to A as it still has all of A's messages. > We could think of a connection establishment and teardown protocol used by all of the unicast protocols, which establishes connections similar to TCP. Senders would block until a connection is established etc and new conn-ids would be created, plus the current send- and receive- seqnos would be exchanged. This could also be used as a second line of defense, to re-establish the connection when a sender doesn't find messages requested for retransmission by a receiver. As an alternative, we could create a new protocol which syncs a receive table with a sender, e.g. https://issues.jboss.org/browse/JGRP-1875. > To mitigate the above issue, {{FD_ALL}} rather than {{FD}} should be used, so that members suspect each other more or less at the same time. This is not the case with FD, where multiple hung (or GC'ing) members take N * timeout time to suspect. With {{FD_ALL}}, chances are that A and B suspect each other and later, both establish a new connection. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2569) Components in Web and EJB container should always have access to RAR included in the same EAR

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2569?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2569: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1029260|https://bugzilla.redhat.com/show_bug.cgi?id=1029260] from POST to ASSIGNED > Components in Web and EJB container should always have access to RAR included in the same EAR > --------------------------------------------------------------------------------------------- > > Key: WFLY-2569 > URL: https://issues.jboss.org/browse/WFLY-2569 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Class Loading, EE > Affects Versions: 8.0.0.Beta1 > Reporter: Martin Kouba > Assignee: Stuart Douglas > Fix For: 8.1.0.Final > > > See also EE.8.3 Class Loading Requirements. > In the mentioned Arquillian test (servlet protocol) if a class from an EJB module tries to access a class from an RAR you get a NoClassDefFoundError. I also tried to place the class in the WAR with the same result. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3263) ear-sub-deployments-isolated is ignored from jboss-deployment-structure.xml

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3263?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3263: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1029260|https://bugzilla.redhat.com/show_bug.cgi?id=1029260] from POST to ASSIGNED > ear-sub-deployments-isolated is ignored from jboss-deployment-structure.xml > --------------------------------------------------------------------------- > > Key: WFLY-3263 > URL: https://issues.jboss.org/browse/WFLY-3263 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EE > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.1.0.CR2, 8.1.0.Final > > > The default processor runs later, and overwrites the value provided by this file. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-585) inconsistent behavior of & bitwise operator

by Rahul Singh (JIRA)

Rahul Singh created DROOLS-585: ---------------------------------- Summary: inconsistent behavior of & bitwise operator Key: DROOLS-585 URL: https://issues.jboss.org/browse/DROOLS-585 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.6.0.Final Reporter: Rahul Singh Assignee: Mark Proctor inconsistent behavior of & bitwise operator after writing a rule given below no-loop when f: Person( ((101 & age) != 0) ) then f.setFound(true); end after calling this several times say 100 it gives in consistent result. Similar behavior is observed if we place bitwise '&' with bitwise '|' -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3701) Investigate HTTPSManagementInterfaceTestCase.testHTTPS and HTTPSWebConnectorTestCase.testVerifyingConnector failures

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3701?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3701: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1135329 > Investigate HTTPSManagementInterfaceTestCase.testHTTPS and HTTPSWebConnectorTestCase.testVerifyingConnector failures > --------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3701 > URL: https://issues.jboss.org/browse/WFLY-3701 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 9.0.0.Beta1 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > Those tests are failing on Brontes: > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=19132&tab=buil... > Need to investigate -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3744) ServletContext.getContextPath() for ROOT.war should be "", not "/"

by Sean Flanigan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3744?page=com.atlassian.jira.plugin.... ] Sean Flanigan commented on WFLY-3744: ------------------------------------- A workaround which seems to help: create an Undertow ServletExtension which does DeploymentInfo.setContextPath("") when ServletContext.getContextPath() returns "/". This might have side effects though, because it's unclear whether DeploymentInfo's definition of contextPath (no JavaDocs) agrees with ServletContext.getContextPath(). > ServletContext.getContextPath() for ROOT.war should be "", not "/" > ------------------------------------------------------------------ > > Key: WFLY-3744 > URL: https://issues.jboss.org/browse/WFLY-3744 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Reporter: Sean Flanigan > Assignee: Stuart Douglas > Attachments: ROOT.war > > > According to JavaDocs (ServletContext.getContextPath and HttpServletRequest.getContextPath): "For servlets in the default (root) context, this method returns "". " > Using latest 9.0.0.Alpha1-SNAPSHOT nightly build from https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ the value is returned in both cases as "/" rather than "" (empty string). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3269) XML parsing mandating the 'force' attribute on username-to-dn even though it has a default value.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3269?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3269: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1133961|https://bugzilla.redhat.com/show_bug.cgi?id=1133961] from POST to MODIFIED > XML parsing mandating the 'force' attribute on username-to-dn even though it has a default value. > ------------------------------------------------------------------------------------------------- > > Key: WFLY-3269 > URL: https://issues.jboss.org/browse/WFLY-3269 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Emmanuel Hugonnet > Fix For: 9.0.0.Beta1 > > > {code} > Trying so, I run in the error (when starting WildFly) : > 10:28:29,674 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[76,25] > Message: JBAS014724: Missing required attribute(s): FORCE > at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:134) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.domain.management.parsing.ManagementXml.parseUsernameToDn_2_0(ManagementXml.java:2118) [wildfly-domain-management-8.0.0.Final.jar:8.0.0.Final] > {code} > {code} > <security-realm name="MgtRealm"> > <authentication> > <ldap connection="ovodavLDAP" base-dn="ou=People,dc=hydrogenic,dc=local"> >  > <username-filter attribute="uid"/> > </ldap> > </authentication> > <authorization> > <ldap connection="ovodavLDAP"> > <username-to-dn> > <username-filter base-dn="ou=People,dc=hydrogenic,dc=local" recursive="false" attribute="uid" user-dn-attribute="dn" /> > </username-to-dn> > <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid"> > <group-to-principal base-dn="ou=Groups,dc=hydrogenic,dc=local" recursive="true" search-by="DISTINGUISHED_NAME"> > <membership-filter principal-attribute="uniqueMember" /> > </group-to-principal> > </group-search> > </ldap> > </authorization> > </security-realm> > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-950) RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-950?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-950: ---------------------------------------------- Weinan Li <weli(a)redhat.com> changed the Status of [bug 899666|https://bugzilla.redhat.com/show_bug.cgi?id=899666] from ASSIGNED to MODIFIED > RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception > --------------------------------------------------------------------- > > Key: WFLY-950 > URL: https://issues.jboss.org/browse/WFLY-950 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: REST > Reporter: Pavel Janousek > Assignee: Weinan Li > > RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. The major one (also portable defined by JAX-RS standard) is _javax.ws.rs.Application_. When I set this parameter to empty content present behavior is raising exception "java.lang.StringIndexOutOfBoundsException: String index out of range: 0", it is not so good. > I think, this is hard miss-configuration error and deployment description as this one should be rejected and a such application should not be deployed at all with appropriate error message, but not only by messed exception. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3716) Upgrade JAXB to 2.2.5.jboss-2 for bug fixes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3716?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3716: ----------------------------------------------- Rostislav Svoboda <rsvoboda(a)redhat.com> changed the Status of [bug 1127327|https://bugzilla.redhat.com/show_bug.cgi?id=1127327] from ON_QA to VERIFIED > Upgrade JAXB to 2.2.5.jboss-2 for bug fixes > ------------------------------------------- > > Key: WFLY-3716 > URL: https://issues.jboss.org/browse/WFLY-3716 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: XML Frameworks > Reporter: Paul Gier > Assignee: Paul Gier > > Upgrade jaxb to 2.2.5.jboss-2 to include some bug fixes. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-851) Base64Utils class cuts leading zeroes from encoded bytes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-851: -------------------------------------------------- Peter Skopek <pskopek(a)redhat.com> changed the Status of [bug 1125004|https://bugzilla.redhat.com/show_bug.cgi?id=1125004] from NEW to ASSIGNED > Base64Utils class cuts leading zeroes from encoded bytes > -------------------------------------------------------- > > Key: SECURITY-851 > URL: https://issues.jboss.org/browse/SECURITY-851 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: PicketBox_4_0_21.Beta2 > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Blocker > > Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array. > So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes. > For instance: > {code} > encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho" > decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 } > {code} > As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException. > IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014