[JBoss JIRA] (WFLY-5449) Custom socket factory for JGroups subsystem not set correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5449?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5449:
-----------------------------------------------
Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from VERIFIED to ASSIGNED
> Custom socket factory for JGroups subsystem not set correctly
> -------------------------------------------------------------
>
> Key: WFLY-5449
> URL: https://issues.jboss.org/browse/WFLY-5449
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR2
> Reporter: Dennis Reed
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.CR4
>
>
> Wildfly's JChannelFactory tries to set a custom socket factory on the JGroups transport.
> This is not the correct API to use, and it gets overwritten when the JGroups channel starts.
> A custom socket factory should be set on the JChannel.
> The only time the custom socket factory is currently used is if there's a race condition where two channels are started at the same time, and the custom factory is set just before the other channel uses it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (WFCORE-1033) ManagedDatagramSocketBinding and ManagedMulticastSocketBinding throw NPE if created with bind address
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1033?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1033:
-------------------------------------------------
Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from VERIFIED to ASSIGNED
> ManagedDatagramSocketBinding and ManagedMulticastSocketBinding throw NPE if created with bind address
> -----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1033
> URL: https://issues.jboss.org/browse/WFCORE-1033
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.0.0.CR6
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 2.0.0.CR7
>
>
> {noformat}
> &#27;[0m&#27;[31m14:51:47,114 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) 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
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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.NullPointerException
> at org.jboss.as.network.ManagedMulticastSocketBinding.bind(ManagedMulticastSocketBinding.java:78)
> at java.net.MulticastSocket.<init>(MulticastSocket.java:172)
> at org.jboss.as.network.ManagedMulticastSocketBinding.<init>(ManagedMulticastSocketBinding.java:54)
> at org.jboss.as.network.ManagedMulticastSocketBinding.create(ManagedMulticastSocketBinding.java:40)
> at org.jboss.as.network.SocketBindingManagerImpl.createMulticastSocket(SocketBindingManagerImpl.java:82)
> at org.jboss.as.clustering.jgroups.ManagedSocketFactoryNew.createMulticastSocket(ManagedSocketFactoryNew.java:127)
> at org.jgroups.util.Util.createMulticastSocket(Util.java:3089)
> at org.jgroups.protocols.MPING.start(MPING.java:190)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> at org.jgroups.JChannel.startStack(JChannel.java:890)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> {noformat}
> This is because the MulticastSocket and DatagramSocket constructors call bind(...), but the ManagedBindingRegistry is not yet set.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (WFCORE-1212) TestModule does not clean up after itself properly
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1212?page=com.atlassian.jira.plugi... ]
Ken Wills updated WFCORE-1212:
------------------------------
Description:
TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the dir above 'main' and below, leaving behind intermediate dirs.
The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'.
I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step.
Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir.
https://issues.jboss.org/browse/JBEAP-2374
was:
TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the dir above 'main' and below, leaving behind intermediate dirs.
The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'.
I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step.
Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir.
> TestModule does not clean up after itself properly
> --------------------------------------------------
>
> Key: WFCORE-1212
> URL: https://issues.jboss.org/browse/WFCORE-1212
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.4.Final
> Reporter: Brian Stansberry
> Assignee: Ken Wills
>
> TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the dir above 'main' and below, leaving behind intermediate dirs.
> The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'.
> I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step.
> Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir.
> https://issues.jboss.org/browse/JBEAP-2374
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (WFCORE-1215) TestModule does not clean up after itself properly
by Ken Wills (JIRA)
Ken Wills created WFCORE-1215:
---------------------------------
Summary: TestModule does not clean up after itself properly
Key: WFCORE-1215
URL: https://issues.jboss.org/browse/WFCORE-1215
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Affects Versions: 2.0.4.Final
Reporter: Ken Wills
Assignee: Ken Wills
TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the dir above 'main' and below, leaving behind intermediate dirs.
The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'.
I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step.
Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (WFCORE-1212) TestModule does not clean up after itself properly
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1212?page=com.atlassian.jira.plugi... ]
Ken Wills edited comment on WFCORE-1212 at 12/11/15 6:34 PM:
-------------------------------------------------------------
Reproducible in wildfy with:
mvn test -pl testsuite/integration/basic -Dts.basic -Dtest=org.jboss.as.test.integration.weld.modules.deployment.StaticModuleToDeploymentVisibilityEarTest -Dversion.org.wildfly.core=2.0.5.Final-SNAPSHOT
was (Author: luck3y):
Reproducible in wildfy with:
mvn test -pl testsuite/integration/basic -Dts.basic -Dtest=org.jboss.as.test.integration.weld.modules.deployment.StaticModuleToDeploymentVisibilityEarTest
> TestModule does not clean up after itself properly
> --------------------------------------------------
>
> Key: WFCORE-1212
> URL: https://issues.jboss.org/browse/WFCORE-1212
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.4.Final
> Reporter: Brian Stansberry
> Assignee: Ken Wills
>
> TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the dir above 'main' and below, leaving behind intermediate dirs.
> The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'.
> I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step.
> Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (WFCORE-1214) Operation headers not propagated to domain servers when 'composite' op is used
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1214:
----------------------------------------
Summary: Operation headers not propagated to domain servers when 'composite' op is used
Key: WFCORE-1214
URL: https://issues.jboss.org/browse/WFCORE-1214
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.4.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Critical
Fix For: 2.0.5.Final
When the user adds request headers to an op, that are not propagated to the servers during domain rollout if the 'composite' op is involved.
For example, if I add some stdout printing of what the headers are on the various processes and invoke this:
{code}
[domain@localhost:9999 /] batch
[domain@localhost:9999 / #] /system-property=add(value=bar){blocking-timeout=10;rollback-on-runtime-failure=false;allow-resource-service-retart=true}
[domain@localhost:9999 / #] run-batch
{code}
Then on a slave with two servers, this is logged:
{code}
[Host Controller] 17:10:11,104 INFO [stdout] (Host Controller Service Threads - 8) "composite" headers: {
[Host Controller] 17:10:11,104 INFO [stdout] (Host Controller Service Threads - 8) "caller-type" => "user",
[Host Controller] 17:10:11,104 INFO [stdout] (Host Controller Service Threads - 8) "access-mechanism" => "NATIVE",
[Host Controller] 17:10:11,104 INFO [stdout] (Host Controller Service Threads - 8) "domain-uuid" => "9adebc93-b318-4624-a26a-c08f53c6a503",
[Host Controller] 17:10:11,104 INFO [stdout] (Host Controller Service Threads - 8) "execute-for-coordinator" => true,
[Host Controller] 17:10:11,105 INFO [stdout] (Host Controller Service Threads - 8) "domain-controller-lock-id" => 38525532
[Host Controller] 17:10:11,105 INFO [stdout] (Host Controller Service Threads - 8) }
[Host Controller] 17:10:11,146 INFO [stdout] (Host Controller Service Threads - 9) "composite" headers: null
[Host Controller] 17:10:11,147 INFO [stdout] (Host Controller Service Threads - 10) "composite" headers: null
[Server:server-one] 17:10:11,152 INFO [stdout] (ServerService Thread Pool -- 68) "composite" headers: {"domain-uuid" => "4ee59ca6-59dd-445f-99a5-190d00df34e0"}
[Server:server-two] 17:10:11,166 INFO [stdout] (ServerService Thread Pool -- 68) "composite" headers: {"domain-uuid" => "3da079cd-c0df-404d-9b1d-99b14a5ce7c2"}
{code}
The HC logs 3 requests; the rollout to itself and the calls it is proxying to the 2 servers. Then the servers report. The user-specified headers are not included.
Invoke the same op without the batch and this is logged:
{code}
[Host Controller] 17:15:51,856 INFO [stdout] (Host Controller Service Threads - 13) "add" headers: {
[Host Controller] 17:15:51,857 INFO [stdout] (Host Controller Service Threads - 13) "blocking-timeout" => "10",
[Host Controller] 17:15:51,857 INFO [stdout] (Host Controller Service Threads - 13) "rollback-on-runtime-failure" => "false",
[Host Controller] 17:15:51,857 INFO [stdout] (Host Controller Service Threads - 13) "allow-resource-service-retart" => "true",
[Host Controller] 17:15:51,857 INFO [stdout] (Host Controller Service Threads - 13) "caller-type" => "user",
[Host Controller] 17:15:51,858 INFO [stdout] (Host Controller Service Threads - 13) "access-mechanism" => "NATIVE",
[Host Controller] 17:15:51,858 INFO [stdout] (Host Controller Service Threads - 13) "domain-uuid" => "a4fe2ef5-31bb-4297-b1fb-19bb91684452",
[Host Controller] 17:15:51,858 INFO [stdout] (Host Controller Service Threads - 13) "execute-for-coordinator" => true,
[Host Controller] 17:15:51,858 INFO [stdout] (Host Controller Service Threads - 13) "domain-controller-lock-id" => -351448963
[Host Controller] 17:15:51,858 INFO [stdout] (Host Controller Service Threads - 13) }
[Host Controller] 17:15:51,879 INFO [stdout] (Host Controller Service Threads - 14) "add" headers: {
[Host Controller] 17:15:51,879 INFO [stdout] (Host Controller Service Threads - 14) "blocking-timeout" => "10",
[Host Controller] 17:15:51,880 INFO [stdout] (Host Controller Service Threads - 14) "rollback-on-runtime-failure" => "false",
[Host Controller] 17:15:51,880 INFO [stdout] (Host Controller Service Threads - 14) "allow-resource-service-retart" => "true",
[Host Controller] 17:15:51,880 INFO [stdout] (Host Controller Service Threads - 14) "access-mechanism" => "NATIVE",
[Host Controller] 17:15:51,880 INFO [stdout] (Host Controller Service Threads - 14) "domain-uuid" => "a4fe2ef5-31bb-4297-b1fb-19bb91684452",
[Host Controller] 17:15:51,880 INFO [stdout] (Host Controller Service Threads - 14) "push-to-servers" => undefined
[Host Controller] 17:15:51,880 INFO [stdout] (Host Controller Service Threads - 14) }
[Host Controller] 17:15:51,881 INFO [stdout] (Host Controller Service Threads - 15) "add" headers: {
[Host Controller] 17:15:51,882 INFO [stdout] (Host Controller Service Threads - 15) "blocking-timeout" => "10",
[Host Controller] 17:15:51,883 INFO [stdout] (Host Controller Service Threads - 15) "rollback-on-runtime-failure" => "false",
[Host Controller] 17:15:51,884 INFO [stdout] (Host Controller Service Threads - 15) "allow-resource-service-retart" => "true",
[Host Controller] 17:15:51,884 INFO [stdout] (Host Controller Service Threads - 15) "access-mechanism" => "NATIVE",
[Host Controller] 17:15:51,884 INFO [stdout] (Host Controller Service Threads - 15) "domain-uuid" => "a4fe2ef5-31bb-4297-b1fb-19bb91684452",
[Host Controller] 17:15:51,884 INFO [stdout] (Host Controller Service Threads - 15) "push-to-servers" => undefined
[Host Controller] 17:15:51,885 INFO [stdout] (Host Controller Service Threads - 15) }
[Server:server-one] 17:15:51,889 INFO [stdout] (ServerService Thread Pool -- 71) "add" headers: {
[Server:server-one] 17:15:51,889 INFO [stdout] (ServerService Thread Pool -- 71) "blocking-timeout" => "10",
[Server:server-one] 17:15:51,890 INFO [stdout] (ServerService Thread Pool -- 71) "rollback-on-runtime-failure" => "false",
[Server:server-one] 17:15:51,890 INFO [stdout] (ServerService Thread Pool -- 71) "allow-resource-service-retart" => "true",
[Server:server-one] 17:15:51,890 INFO [stdout] (ServerService Thread Pool -- 71) "access-mechanism" => "NATIVE",
[Server:server-one] 17:15:51,890 INFO [stdout] (ServerService Thread Pool -- 71) "domain-uuid" => "a4fe2ef5-31bb-4297-b1fb-19bb91684452",
[Server:server-one] 17:15:51,890 INFO [stdout] (ServerService Thread Pool -- 71) "push-to-servers" => undefined
[Server:server-one] 17:15:51,890 INFO [stdout] (ServerService Thread Pool -- 71) }
[Server:server-two] 17:15:51,891 INFO [stdout] (ServerService Thread Pool -- 70) "add" headers: {
[Server:server-two] 17:15:51,891 INFO [stdout] (ServerService Thread Pool -- 70) "blocking-timeout" => "10",
[Server:server-two] 17:15:51,892 INFO [stdout] (ServerService Thread Pool -- 70) "rollback-on-runtime-failure" => "false",
[Server:server-two] 17:15:51,892 INFO [stdout] (ServerService Thread Pool -- 70) "allow-resource-service-retart" => "true",
[Server:server-two] 17:15:51,892 INFO [stdout] (ServerService Thread Pool -- 70) "access-mechanism" => "NATIVE",
[Server:server-two] 17:15:51,892 INFO [stdout] (ServerService Thread Pool -- 70) "domain-uuid" => "a4fe2ef5-31bb-4297-b1fb-19bb91684452",
[Server:server-two] 17:15:51,892 INFO [stdout] (ServerService Thread Pool -- 70) "push-to-servers" => undefined
{code}
Expected headers are present.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months