[JBoss JIRA] (WFCORE-1077) Properties authentication in Security Realms does not work with equals sign in password
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1077?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1077:
-------------------------------------
Summary: Properties authentication in Security Realms does not work with equals sign in password (was: Properties authentication in Security Realms does not work with equation mark in password)
> Properties authentication in Security Realms does not work with equals sign in password
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1077
> URL: https://issues.jboss.org/browse/WFCORE-1077
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.0.CR8
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> Security realm doesnt start in case when password contains "\=" e.g. {code}user5=Pass\=word1{code}.
> Thrown exception is
> {code}
> ^[[0m^[[31m07:00:10,342 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.server.controller.management.security_realm.DelimitersRealm.properties_authentication: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.DelimitersRealm.properties_authentication: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 11
> at org.jboss.as.domain.management.security.PropertiesFileLoader.cleanKey(PropertiesFileLoader.java:236)
> at org.jboss.as.domain.management.security.UserPropertiesFileLoader.load(UserPropertiesFileLoader.java:106)
> at org.jboss.as.domain.management.security.PropertiesFileLoader.loadAsRequired(PropertiesFileLoader.java:164)
> at org.jboss.as.domain.management.security.PropertiesFileLoader.getProperties(PropertiesFileLoader.java:144)
> at org.jboss.as.domain.management.security.PropertiesFileLoader.start(PropertiesFileLoader.java:131)
> at org.jboss.as.domain.management.security.PropertiesCallbackHandler.start(PropertiesCallbackHandler.java:128)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5680) InfinispanBatchContext trying to resume commited txn
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5680?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-5680:
-------------------------------------------
This was tested with master, although it applies to 10.0.0CR4.
> InfinispanBatchContext trying to resume commited txn
> ----------------------------------------------------
>
> Key: WFLY-5680
> URL: https://issues.jboss.org/browse/WFLY-5680
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Environment: Linux x86_64
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
> Attachments: resume-commited-txn-output.txt
>
>
> When running the test case RemoteFailoverTestCase.testStatefulFailover, the test hangs due to an exception occurring. The exception is the following:
> {noformat}
> [31m11:24:05,814 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (EJB default - 3) ISPN000136: Execution error: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=47}, status=3} is not in a valid state to be invoking cache operations on.
> {noformat}
> This exception arose some time ago and was linked to incorrect suspend/resume of threads by the InfinispanBatching mechanism. This is just a suggestion as to what might be the root cause.
> Attached is a log of the test case run with TRACE logging on DummyTransactionManager which coordinates the suspends and resumes. I have also performed a stack trace dump on every call to suspend and resume to highlight the origin of the call.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5680) InfinispanBatchContext trying to resume commited txn
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created WFLY-5680:
-----------------------------------------
Summary: InfinispanBatchContext trying to resume commited txn
Key: WFLY-5680
URL: https://issues.jboss.org/browse/WFLY-5680
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.CR4
Environment: Linux x86_64
Reporter: Richard Achmatowicz
Assignee: Paul Ferraro
Attachments: resume-commited-txn-output.txt
When running the test case RemoteFailoverTestCase.testStatefulFailover, the test hangs due to an exception occurring. The exception is the following:
{noformat}
[31m11:24:05,814 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (EJB default - 3) ISPN000136: Execution error: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=47}, status=3} is not in a valid state to be invoking cache operations on.
{noformat}
This exception arose some time ago and was linked to incorrect suspend/resume of threads by the InfinispanBatching mechanism. This is just a suggestion as to what might be the root cause.
Attached is a log of the test case run with TRACE logging on DummyTransactionManager which coordinates the suspends and resumes. I have also performed a stack trace dump on every call to suspend and resume to highlight the origin of the call.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5679) Classloading issue when running test by using both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed together
by Matous Jobanek (JIRA)
Matous Jobanek created WFLY-5679:
------------------------------------
Summary: Classloading issue when running test by using both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed together
Key: WFLY-5679
URL: https://issues.jboss.org/browse/WFLY-5679
Project: WildFly
Issue Type: Bug
Reporter: Matous Jobanek
Assignee: Jason Greene
When there is a test starting both containers WF9 and JBoss AS 7 (eg. for migration verification) the deployment and stopping of the containers don't behave correctly. To start both of the containers I need relevant container adapters:
- {{org.jboss.as:jboss-as-arquillian-container-managed}}
- {{org.wildfly.arquillian:wildfly-arquillian-container-managed (or org.wildfly:wildfly-arquillian-container-managed for WF8)}}
however, in the case of the WF's adapter the packages haven't been renamed (when there was the migration from the JBoss AS to WF, even though the maven artifact had been renamed).
The situation of using both of the artifacts leads to the situation that there are two Java classes with the very same name (eg. {{org.jboss.as.arquillian.container.managed.ManagedContainerExtension}}) and only one of them is used - the one that belongs to the artifact used as the first one there in the pom.xml file.
So, currently there is no easy way how to run two or more containers in a combination of WF8+ and JBoss AS 7 (and older).
This leads me to the main question - why the packages haven't been renamed after the migration to org.wildfly(.arquillian) ? Current situation is quite confusing and in some cases problematic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5678) [Migration operation] :migrate operation should return outcome success when migrating expressions jgroup stack in discovery group
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5678?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-1911 to WFLY-5678:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5678 (was: JBEAP-1911)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: JMS
(was: JMS)
(was: Migration)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR4
(was: 7.0.0.DR13 (Alpha))
> [Migration operation] :migrate operation should return outcome success when migrating expressions jgroup stack in discovery group
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5678
> URL: https://issues.jboss.org/browse/WFLY-5678
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> If configuration for jgroups stack in discovery group contains expression:
> {code}
> <discovery-group name="groupU">
> <jgroups-stack>${jgroups.stack:udp}</jgroups-stack>
> <jgroups-channel>${jgroups.channel:udp}</jgroups-channel>
> </discovery-group>
> {code}
> then :migrate operation has {{outcome => failed}}:
> {code}
> [standalone@127.0.0.1:9999 /] /subsystem=messaging:migrate
> {
> "outcome" => "failed",
> "result" => {
> "migration-warnings" => [],
> "migration-error" => {
> "operation" => {
> "jgroups-stack" => expression "${jgroups.stack:udp}",
> "jgroups-channel" => expression "${jgroups.channel:udp}",
> "operation" => "add",
> "address" => [
> ("subsystem" => "messaging-activemq"),
> ("server" => "default"),
> ("discovery-group" => "groupU")
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE"
> }
> },
> "result" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0264: jgroups-stack may not be ModelType.EXPRESSION",
> "rolled-back" => true
> }
> }
> },
> "failure-description" => "WFLYMSG0081: Migration failed, see results for more details.",
> "rolled-back" => true
> }
> {code}
> Based on my understanding there should be outcome success with warning.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration
by Andrig Miller (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ]
Andrig Miller closed WFCORE-1132.
---------------------------------
Resolution: Done
Okay, sorry for the wild goose chase. It turns out that what we were seeing in the socket options was actually the PostgreSQL sockets being set.
> Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1132
> URL: https://issues.jboss.org/browse/WFCORE-1132
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Andrig Miller
> Priority: Blocker
> Fix For: 2.0.2.Final (EAP 7)
>
>
> Original report:
> {quote}
> In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit.
> So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration.
> {quote}
> This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1132:
--------------------------------
Comment: was deleted
(was: It is set in Remoting subsystem
we do
{code:java}
OptionAttributeDefinition RECEIVE_BUFFER_SIZE = OptionAttributeDefinition.builder("receive-buffer-size", RemotingOptions.RECEIVE_BUFFER_SIZE)
.setDefaultValue(new ModelNode(RemotingOptions.DEFAULT_RECEIVE_BUFFER_SIZE))
.setAllowExpression(true)
.build();
{code}
I can send a PR to not have default values set for this.)
> Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1132
> URL: https://issues.jboss.org/browse/WFCORE-1132
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Andrig Miller
> Priority: Blocker
> Fix For: 2.0.2.Final (EAP 7)
>
>
> Original report:
> {quote}
> In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit.
> So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration.
> {quote}
> This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1132:
-------------------------------------
You are right David, sorry for adding confusion to thread, removed the comment just to remove noise.
> Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1132
> URL: https://issues.jboss.org/browse/WFCORE-1132
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Andrig Miller
> Priority: Blocker
> Fix For: 2.0.2.Final (EAP 7)
>
>
> Original report:
> {quote}
> In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit.
> So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration.
> {quote}
> This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1132) Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1132?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1132:
-------------------------------------
Something!
> Only set socket send and receive buffer sizes if it is in the Remoting subsystem configuration
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1132
> URL: https://issues.jboss.org/browse/WFCORE-1132
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Andrig Miller
> Priority: Blocker
> Fix For: 2.0.2.Final (EAP 7)
>
>
> Original report:
> {quote}
> In our testing of Wildfy 10 CR4, in the performance lab, we found that one of the differences between EAP 6.4.x and Wildfly 10 was that EAP does not set the socket send and receive buffers. We changed the configuration of Wildfly (Undertow) to remove the buffer parameters from the configuration, and we found that the buffer sizes were still be set to 8k. We hacked XNIO to comment out the setting of these parameters, and latency improved quite a bit.
> So, we need a permanent fix so that the socket send and receive buffers are only set, if they are specified in the configuration.
> {quote}
> This applies to the Remoting subsystem configuration, versions 2.0 and onwards, and also possibly to Undertow, though that subsystem does not appear to use default values.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months