[JBoss JIRA] (WFLY-5912) "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers a "phantom" DS
by Danilo Cominotti Marques (JIRA)
[ https://issues.jboss.org/browse/WFLY-5912?page=com.atlassian.jira.plugin.... ]
Danilo Cominotti Marques updated WFLY-5912:
-------------------------------------------
Summary: "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers a "phantom" DS (was: "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS)
> "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers a "phantom" DS
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5912
> URL: https://issues.jboss.org/browse/WFLY-5912
> Project: WildFly
> Issue Type: Bug
> Components: Server, Web Console
> Affects Versions: 10.0.0.CR5
> Reporter: Danilo Cominotti Marques
> Assignee: Jason Greene
> Attachments: WebConsole.jpg
>
>
> After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
> 22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "CominottiDS")
> ]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (WFLY-5912) "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
by Danilo Cominotti Marques (JIRA)
[ https://issues.jboss.org/browse/WFLY-5912?page=com.atlassian.jira.plugin.... ]
Danilo Cominotti Marques updated WFLY-5912:
-------------------------------------------
Attachment: WebConsole.jpg
Screenshot taken after clicking on "Test connection"
> "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5912
> URL: https://issues.jboss.org/browse/WFLY-5912
> Project: WildFly
> Issue Type: Bug
> Components: Server, Web Console
> Affects Versions: 10.0.0.CR5
> Reporter: Danilo Cominotti Marques
> Assignee: Jason Greene
> Attachments: WebConsole.jpg
>
>
> After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
> 22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "CominottiDS")
> ]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (WFLY-5912) "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
by Danilo Cominotti Marques (JIRA)
Danilo Cominotti Marques created WFLY-5912:
----------------------------------------------
Summary: "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
Key: WFLY-5912
URL: https://issues.jboss.org/browse/WFLY-5912
Project: WildFly
Issue Type: Bug
Components: Server, Web Console
Affects Versions: 10.0.0.CR5
Reporter: Danilo Cominotti Marques
Assignee: Jason Greene
After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
{{22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "CominottiDS")
]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
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)}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (WFLY-5912) "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
by Danilo Cominotti Marques (JIRA)
[ https://issues.jboss.org/browse/WFLY-5912?page=com.atlassian.jira.plugin.... ]
Danilo Cominotti Marques updated WFLY-5912:
-------------------------------------------
Description:
After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "CominottiDS")
]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
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)
was:
After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
{{22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "CominottiDS")
]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
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)}}
> "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5912
> URL: https://issues.jboss.org/browse/WFLY-5912
> Project: WildFly
> Issue Type: Bug
> Components: Server, Web Console
> Affects Versions: 10.0.0.CR5
> Reporter: Danilo Cominotti Marques
> Assignee: Jason Greene
>
> After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
> 22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "CominottiDS")
> ]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (WFLY-5758) Getting [Management resource '[(\"subsystem\" => \"undertow\")]' not found] when removing ressources from Undertow
by Montpa Pasteur (JIRA)
[ https://issues.jboss.org/browse/WFLY-5758?page=com.atlassian.jira.plugin.... ]
Montpa Pasteur commented on WFLY-5758:
--------------------------------------
I haven't tried it yet, but is there any chance to have this fix for Wildfly 8.2.1 ?
Thanks.
> Getting [Management resource '[(\"subsystem\" => \"undertow\")]' not found] when removing ressources from Undertow
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5758
> URL: https://issues.jboss.org/browse/WFLY-5758
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 8.x.x TBD
> Environment: Wildfly 8.2.1 on SUSE Linux 11.1 and Solaris 11
> Reporter: Montpa Pasteur
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> When trying remove more that one resource from Undertow using the CLI, I am getting this message: *[Management resource '[(\"subsystem\" => \"undertow\")]' not found*]
> This doesn't happen all time, it looks like random. Adding a sleep between the CLI command helps some time.
> I get this problem when trying to remove http request header configuration and when trying to remove static ressource serving configuration(location, file handler, filter ..)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1985:
--------------------------------
Hmm, by default we have the following headers
* Transport: {{UDP}}, {{TCP}} or {{TCP_NIO2}}
* Reliable retransmission and ordering protocol: either {{NAKACK2}} or {{UNICAST3}}
* RequestCorrelator for RPCs
That's 3 headers most of the time. Which other headers did you see? {{FRAG2}}?
Just out of curiosity, I'll change the default to 4 anyway.
> Message: make initial size of headers configurable
> --------------------------------------------------
>
> Key: JGRP-1985
> URL: https://issues.jboss.org/browse/JGRP-1985
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays.
> Goal: make the initial headers size configurable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1985 at 12/24/15 5:27 AM:
----------------------------------------------------------
Hmm, by default we have the following headers
* Transport: {{UDP}}, {{TCP}} or {{TCP_NIO2}}
* Reliable retransmission and ordering protocol: either {{NAKACK2}} or {{UNICAST3}}
* RequestCorrelator for RPCs
That's 3 headers most of the time. Which other headers did you see? {{FRAG2}}, {{FORK}}?
Just out of curiosity, I'll change the default to 4 anyway.
was (Author: belaban):
Hmm, by default we have the following headers
* Transport: {{UDP}}, {{TCP}} or {{TCP_NIO2}}
* Reliable retransmission and ordering protocol: either {{NAKACK2}} or {{UNICAST3}}
* RequestCorrelator for RPCs
That's 3 headers most of the time. Which other headers did you see? {{FRAG2}}?
Just out of curiosity, I'll change the default to 4 anyway.
> Message: make initial size of headers configurable
> --------------------------------------------------
>
> Key: JGRP-1985
> URL: https://issues.jboss.org/browse/JGRP-1985
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays.
> Goal: make the initial headers size configurable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JGRP-1999) TCP_NIO2: single selector slows down writes and reads
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1999?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1999.
----------------------------
Resolution: Done
> TCP_NIO2: single selector slows down writes and reads
> -----------------------------------------------------
>
> Key: JGRP-1999
> URL: https://issues.jboss.org/browse/JGRP-1999
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> TCP_NIO2 has a single selector which looks like this:
> {noformat}
> x=select()
> if(read) -> read data from connection x, de-serialize data, pass to thread pool
> if(write) -> write data pending on connection x
> {noformat}
> This means that any operation (read,write) delays other operations. It seems that especially the de-serialization done in reads delays other reads and writes.
> A quick test showed that having a reader thread per connection (so that reads don't delay other reads or writes) improved perf from 15'000 reqs/sec to 22'000.
> The idea is to have a reader thread in {{NioConnection}} which reads and de-serializes as many messages as possible. When no more messages are ready to be read, it blocks for a max wait time and then terminates unless more messages are ready. This means that idle connections will have no threads allocated.
> Investigate: we might possibly also null the pre-allocated buffer when a thread terminates, reducing memory usage even more.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JGRP-1999) TCP_NIO2: single selector slows down writes and reads
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1999?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1999:
--------------------------------
{{OP_READ}} is unregistered on each {{receive()}}, and re-registered when the reader thread is done reading msgs. Quick perf test (UPerf, 4 nodes) showed perf of *~24'000 RPCs/sec/node*, which is equivalent to {{TCP}}.
> TCP_NIO2: single selector slows down writes and reads
> -----------------------------------------------------
>
> Key: JGRP-1999
> URL: https://issues.jboss.org/browse/JGRP-1999
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> TCP_NIO2 has a single selector which looks like this:
> {noformat}
> x=select()
> if(read) -> read data from connection x, de-serialize data, pass to thread pool
> if(write) -> write data pending on connection x
> {noformat}
> This means that any operation (read,write) delays other operations. It seems that especially the de-serialization done in reads delays other reads and writes.
> A quick test showed that having a reader thread per connection (so that reads don't delay other reads or writes) improved perf from 15'000 reqs/sec to 22'000.
> The idea is to have a reader thread in {{NioConnection}} which reads and de-serializes as many messages as possible. When no more messages are ready to be read, it blocks for a max wait time and then terminates unless more messages are ready. This means that idle connections will have no threads allocated.
> Investigate: we might possibly also null the pre-allocated buffer when a thread terminates, reducing memory usage even more.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months