August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1260) Remove workaround for shutting down the ModelControllerClientOperationHandlers

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-1260?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber resolved WFLY-1260. --------------------------------------- Assignee: Emanuel Muckenhuber Fix Version/s: 9.0.0.Beta1 Resolution: Done Yeah, I agree. I actually did this in upstream already, so i am going to resolve this issue. Thanks for spotting that issue. > Remove workaround for shutting down the ModelControllerClientOperationHandlers > ------------------------------------------------------------------------------ > > Key: WFLY-1260 > URL: https://issues.jboss.org/browse/WFLY-1260 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 9.0.0.Beta1 > > > Once the graceful shutdown API is in place we need to cleanup the way the ModelControllerClientOperationHandler channels are closed. Currently we are waiting for all current operations to complete, in order that the response for :reload / :shutdown operations are sent. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBAS-4733) "Another ORA-00907: missing right parenthesis" bug with Oracle

by Thomas Scheibelreiter (JIRA)

[ https://issues.jboss.org/browse/JBAS-4733?page=com.atlassian.jira.plugin.... ] Thomas Scheibelreiter commented on JBAS-4733: --------------------------------------------- Hi, since this issue pops up at the top of Google search results, I want to inform everybody who stumbles upon this problem, that it persists in later releases. But there is a workaround: Leave the "SELECT xyz" from the subquery. Without it, there are no parenthesis created in the SELECT-clause. > "Another ORA-00907: missing right parenthesis" bug with Oracle > -------------------------------------------------------------- > > Key: JBAS-4733 > URL: https://issues.jboss.org/browse/JBAS-4733 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: JBossAS-4.2.1.GA > Environment: hibernate-entitymanager.jar (3.3.1ga) > hibernate-annotations.jar (v 3.3.0ga) > hibernate-commons-annotations.jar (within Hibernate Annotations.rar\lib) > ejb3-persistence.jar (within Hibernate Annotations.rar\lib) > hibernate3.jar (v 3.2.5.ga) > Oracle 10g > JBossAS-4.2.1GA > Reporter: Dean Pullen > Assignee: Steve Ebersole > Fix For: No Release > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I'm using JBoss 4.2.1GA, with the Hibernate environment described above, using Oracle 10g, and attempting to perform a query. > I've been receiving a "ORA-00907: missing right parenthesis" error when attempting to perform the query. > Now a similar bug had this down to Hibernate using the 'as' keyword in the query, aliasing the table name - something that has been fixed in Hibernate 3.3.0ga. > (Aliasing a table in the SQL spec is optional, Oracle doesn't support it) > But I still get the same error. The query still contains the 'as' keyword (but not aliasing a table) > Here is an example: > I have two tables. CSIUsers and CSIUserSurveys. > There is a one-to-many mapping between CSIUsers to CSIUserSurveys. > Query query = entityManager.createQuery("FROM " + CSIUser.class.getSimpleName() > + " cu LEFT JOIN cu.csiUserSurveys us" > + " WHERE NOT EXISTS (SELECT us FROM cu.csiUserSurveys us WHERE us.csiUserId = cu.csiUserId)"); > Result: > [[14 Sep 2007 15:43:52] DEBUG org.hibernate.util.JDBCExceptionReporter - could n > ot execute query [select csiuser0_.CSI_USER_ID as CSI1_15_0_, csiusersur1_.CSI_U > SER_ID as CSI1_16_1_, csiusersur1_.SURVEY_TYPE_CODE as SURVEY2_16_1_, csiuser0_. > COMPANY_CODE as COMPANY2_15_0_, csiuser0_.EMAIL_ADDRESS as EMAIL3_15_0_, csiuser > 0_.FAILED_LOGINS as FAILED4_15_0_, csiuser0_.LOCALE as LOCALE15_0_, csiuser0_.PA > SSWORD as PASSWORD15_0_, csiuser0_.PURCHASE_DATE as PURCHASE7_15_0_, csiuser0_.S > TATUS as STATUS15_0_, csiuser0_.USER_NAME as USER9_15_0_, csiuser0_.USER_PRIVILE > GE as USER10_15_0_, csiusersur1_.SURVEY_INVITE_DATE as SURVEY3_16_1_ from CSI_US > ERS csiuser0_ left outer join CSI_USER_SURVEYS csiusersur1_ on csiuser0_.CSI_USE > R_ID=csiusersur1_.CSI_USER_ID where not (exists (select (csiusersur2_.CSI_USER_ > ID, csiusersur2_.SURVEY_TYPE_CODE) from CSI_USER_SURVEYS csiusersur2_ where csiu > ser0_.CSI_USER_ID=csiusersur2_.CSI_USER_ID and csiusersur2_.CSI_USER_ID=csiuser0 > _.CSI_USER_ID))] > java.sql.SQLException: ORA-00907: missing right parenthesis -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1874) UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1874?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1874: --------------------------- Fix Version/s: 3.5.1 3.6 (was: 3.5) > UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO > ----------------------------------------------------------- > > Key: JGRP-1874 > URL: https://issues.jboss.org/browse/JGRP-1874 > Project: JGroups > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic. > Example: > # B has no entry for A in its recv-table > # A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message > # If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A > #* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO}} message: too much traffic > # A now sends messages {{A::101}} - {{A::560}} to B > #* This is also not needed: too much traffic > h5. Solution to reduce traffic > * Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the previous one > ** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_ > * Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B > ** B will then retransmit all missing messages in that range > ** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1875: --------------------------- Fix Version/s: 3.5.1 3.6 (was: 3.5) > UNICAST3/UNICAST2: sync receiver table with sender table > -------------------------------------------------------- > > Key: JGRP-1875 > URL: https://issues.jboss.org/browse/JGRP-1875 > Project: JGroups > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}). > To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g. > * B needs to get the lowest and highest seqno sent from A > * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message) > * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}} > * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos > * B creates an entry for A with the lowest and highest seqnos > * B sends a {{SYNC-ACK}} to A > * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again > * A and B now use the usual protocols to retransmit missing messages -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[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, 8 months

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, 8 months

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, 8 months

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, 8 months

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, 8 months

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, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014