[JBoss JIRA] (WFLY-3791) Error on ModelControllerClient to list sections
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3791?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3791:
----------------------------------------
Yes I understand you are using the latest version, however are you using the default configuration or a clean configuration? Looking at your test code it is on the basis that you are using a modified configuration - what I am asking is that you run your test against an unmodified version of the configuration.
An no at this point I have not tried your java code, I have just verified that the security subsystem is accessible on a default installation at the same address as it has always been. The thing I need to know now is do you experience this error in a clean installation or only in your customised installation.
> Error on ModelControllerClient to list sections
> -----------------------------------------------
>
> Key: WFLY-3791
> URL: https://issues.jboss.org/browse/WFLY-3791
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Java 7
> Reporter: ofbiz brazil
> Assignee: Darran Lofthouse
>
> Hello,
> When there's a client trying to list a node for a security section, Wildfly says it does not exist but on Jboss 7.1.1 it works fine.
> Java Code:
> --------------
> final ModelNode request = new ModelNode();
> request.get(ClientConstants.OP).set("read-resource");
> request.get("recursive").set(true);
> request.get(ClientConstants.OP_ADDR).add("subsystem", "security");
> final ModelControllerClient client = ModelControllerClient.Factory.create(InetAddress.getByName("127.0.0.1"), 9999);
> final ModelNode response = client.execute(new OperationBuilder(request).build());
> final String section = response.get(ClientConstants.RESULT).get("security-domain")
> .get("pw_MSSQL_CAS_DS")
> Result:
> ---------
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[(\"subsystem\" => \"security\")]' not found",
> "rolled-back" => true
> }
> Cheers,
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 1 month
[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, 1 month
[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, 1 month
[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, 1 month
[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, 1 month