[JBoss JIRA] (WFCORE-1119) ManagedDatagramSocketBinding throw NPE
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1119?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1119:
-------------------------------------
Fix Version/s: 3.0.0.Alpha1
> ManagedDatagramSocketBinding throw NPE
> --------------------------------------
>
> Key: WFCORE-1119
> URL: https://issues.jboss.org/browse/WFCORE-1119
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR8
> Reporter: Stefan Dilk
> Assignee: Jason Greene
> Fix For: 3.0.0.Alpha1
>
>
> i think i have found the same bug as in WFCORE-1033 but in another method.
> in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
> {noformat}
> [Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
> java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
> 6)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
> [Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> [Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
> [Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
> [Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
> [Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> [Server:mgmt-1-prod] ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1119) ManagedDatagramSocketBinding throw NPE
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1119?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1119:
----------------------------------------
Assignee: Brian Stansberry (was: Jason Greene)
> ManagedDatagramSocketBinding throw NPE
> --------------------------------------
>
> Key: WFCORE-1119
> URL: https://issues.jboss.org/browse/WFCORE-1119
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR8
> Reporter: Stefan Dilk
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> i think i have found the same bug as in WFCORE-1033 but in another method.
> in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
> {noformat}
> [Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
> java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
> 6)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
> [Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> [Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
> [Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
> [Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
> [Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> [Server:mgmt-1-prod] ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1009) Treat intra-domain transactional ":reload" and ":shutdown" requests similarly to how we handle end user requests
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1009?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1009.
--------------------------------------
Resolution: Rejected
Sorry, bad idea. :(
> Treat intra-domain transactional ":reload" and ":shutdown" requests similarly to how we handle end user requests
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1009
> URL: https://issues.jboss.org/browse/WFCORE-1009
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
>
> ModelControllerClientOperationHandler.ExecuteRequestHandler has special logic for the ":reload" op such that once the operation notifies that it is prepared, it immediately sends the final "success" result to the client, not waiting for the op execution to return to send it. This allows the response to go out to the client before the reload starts shutting down services. WFCORE-1008 proposes expanding this to the ":shutdown" operation as well.
> This JIRA proposes expanding this to the TransactionalProtocolOperationHandler used for intra-domain process requests as well.
> The implementation here would be slightly different in that the response to the prepared notification from the op would be unchanged. What would change would be the handling of the tx commit coming from the client. The tx commit message handling would send the response instead of waiting for the original op to complete.
> The client side state related to the status of the reloading/shutting down slave HC or server should be fine. A master HC's tracking of slaves is unaffected by proxying a reload or shutdown op; it monitors the master<->slave comm channel to track the slave. Same thing for an HC reloading a server. For the case where an HC is stopping a server by sending a ":shutdown" request, the response to the request puts the HC's view of the server's state into InternalState.PROCESS_STOPPING. This state is valid as soon as the HC commits the ":shutdown" request, so this JIRA is consistent with that handling.
> (Note: This special handling of ":reload" isn't a perfect thing, as it only covers the direct use of the ":reload" op. It doesn't cover things like a reload as a step in a composite. For the composite case, we need to give the step handlers for the other steps a chance to run any ResultHandlers they have registered and fix up the response before we send it back, so we can't just ignore that part of the execution.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1119) ManagedDatagramSocketBinding throw NPE
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1119?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1119:
-------------------------------------
Component/s: Domain Management
(was: Server)
> ManagedDatagramSocketBinding throw NPE
> --------------------------------------
>
> Key: WFCORE-1119
> URL: https://issues.jboss.org/browse/WFCORE-1119
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR8
> Reporter: Stefan Dilk
> Assignee: Jason Greene
>
> i think i have found the same bug as in WFCORE-1033 but in another method.
> in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
> {noformat}
> [Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
> java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
> 6)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
> [Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> [Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
> [Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
> [Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
> [Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> [Server:mgmt-1-prod] ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1124) Recreate BasicOperationsUnitTestCase.testMetricReadAttribute()
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1124?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1124:
-------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1236
> Recreate BasicOperationsUnitTestCase.testMetricReadAttribute()
> --------------------------------------------------------------
>
> Key: WFCORE-1124
> URL: https://issues.jboss.org/browse/WFCORE-1124
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 3.0.0.Alpha1
>
>
> BasicOperationsUnitTestCase.testMetricReadAttribute() was ignored when the test was moved from full to core because the test impl used undertow subsystem resources.
> We should resurrect this test, using resources in core.
> The goal of the test is to read a metric, not to test a metric of a particular resource. So the task is not to move the test to full and test undertow subsystem, it's to make calls against core that read a metric.
> If there is missing coverage in full of reading undertow metrics, that should be a separate JIRA. A much more important one!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1124) Recreate BasicOperationsUnitTestCase.testMetricReadAttribute()
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1124?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1124:
-------------------------------------
Fix Version/s: 3.0.0.Alpha1
> Recreate BasicOperationsUnitTestCase.testMetricReadAttribute()
> --------------------------------------------------------------
>
> Key: WFCORE-1124
> URL: https://issues.jboss.org/browse/WFCORE-1124
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 3.0.0.Alpha1
>
>
> BasicOperationsUnitTestCase.testMetricReadAttribute() was ignored when the test was moved from full to core because the test impl used undertow subsystem resources.
> We should resurrect this test, using resources in core.
> The goal of the test is to read a metric, not to test a metric of a particular resource. So the task is not to move the test to full and test undertow subsystem, it's to make calls against core that read a metric.
> If there is missing coverage in full of reading undertow metrics, that should be a separate JIRA. A much more important one!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1125) Restore support for OperationMessageHandler
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1125:
----------------------------------------
Summary: Restore support for OperationMessageHandler
Key: WFCORE-1125
URL: https://issues.jboss.org/browse/WFCORE-1125
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Priority: Optional
TALK TO BRIAN BEFORE DOING ANYTHING ON THIS
Very early in AS7 the ModelControllerClient API included a functioning notion of an OperationMessageHandler whereby the client could receive out-of-band messages during operation execution. Support for this was dropped well before AS 7.0 went Final, although the interface is still in the API.
This JIRA is to track the task of restoring it. It's low priority. I'm mostly filing this because there are some @Ignored unit tests of it and I want those to link to a JIRA.
The kind of cool original use case I had in mind for this was to track progress during domain rollouts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1124) Recreate BasicOperationsUnitTestCase.testMetricReadAttribute()
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1124?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1124:
----------------------------------------
Assignee: Brian Stansberry
> Recreate BasicOperationsUnitTestCase.testMetricReadAttribute()
> --------------------------------------------------------------
>
> Key: WFCORE-1124
> URL: https://issues.jboss.org/browse/WFCORE-1124
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> BasicOperationsUnitTestCase.testMetricReadAttribute() was ignored when the test was moved from full to core because the test impl used undertow subsystem resources.
> We should resurrect this test, using resources in core.
> The goal of the test is to read a metric, not to test a metric of a particular resource. So the task is not to move the test to full and test undertow subsystem, it's to make calls against core that read a metric.
> If there is missing coverage in full of reading undertow metrics, that should be a separate JIRA. A much more important one!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1124) Recreate BasicOperationsUnitTestCase.testMetricReadAttribute()
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1124:
----------------------------------------
Summary: Recreate BasicOperationsUnitTestCase.testMetricReadAttribute()
Key: WFCORE-1124
URL: https://issues.jboss.org/browse/WFCORE-1124
Project: WildFly Core
Issue Type: Task
Components: Domain Management, Test Suite
Reporter: Brian Stansberry
Priority: Minor
BasicOperationsUnitTestCase.testMetricReadAttribute() was ignored when the test was moved from full to core because the test impl used undertow subsystem resources.
We should resurrect this test, using resources in core.
The goal of the test is to read a metric, not to test a metric of a particular resource. So the task is not to move the test to full and test undertow subsystem, it's to make calls against core that read a metric.
If there is missing coverage in full of reading undertow metrics, that should be a separate JIRA. A much more important one!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months