[JBoss JIRA] (WFLY-10629) Server startup wrongly deploys all xml files and never stops
by Arnie Morein (JIRA)
[ https://issues.jboss.org/browse/WFLY-10629?page=com.atlassian.jira.plugin... ]
Arnie Morein commented on WFLY-10629:
-------------------------------------
I've compared the values in the Eclipse WF 12 launch config settings between OSX and Win7x64. The correlate, and WF starts normally on OSX, not on Win7x64.
> Server startup wrongly deploys all xml files and never stops
> ------------------------------------------------------------
>
> Key: WFLY-10629
> URL: https://issues.jboss.org/browse/WFLY-10629
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 13.0.0.Final
> Reporter: Arnie Morein
> Assignee: Jason Greene
>
> I have downloaded WF 12 and 13, then imported each into Eclipse (Oxygen.3a Release (4.7.3a)), OS is Win 7/x64; then used add-user to set up admin user. Then from both the command line and from within Eclipse, when the software starts up all of the xml configuration files get deployed at the same time despite the fact that the --server-config=standalone.xml parameter is present in either environment. What's worse, it starts versioning them and re-deploying them over and over and over again.
> {quote}
> 15:45:42,229 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 66) WFLYCLINF0002: Started client-mappings cache from ejb container
> 15:45:42,319 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone.xml" (runtime-name : "standalone.xml")
> 15:45:42,320 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone-load-balancer.xml" (runtime-name : "standalone-load-balancer.xml")
> 15:45:42,324 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone-ha.xml" (runtime-name : "standalone-ha.xml")
> 15:45:42,324 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone-full.xml" (runtime-name : "standalone-full.xml")
> 15:45:42,325 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone-full-ha.xml" (runtime-name : "standalone-full-ha.xml")
> 15:45:42,326 INFO [org.jboss.as.server] (ServerService Thread Pool -- 39) WFLYSRV0010: Deployed "standalone-ee8.xml" (runtime-name : "standalone-ee8.xml")
> 15:45:42,407 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 15:45:42,410 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 15:45:42,411 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> 15:45:42,411 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) started in 6285ms - Started 549 of 746 services (326 se
> rvices are lazy, passive or on-demand)
> 15:45:42,575 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "standalone.last.xml" (runtime-name: "standalone.last.xml")
> 15:45:42,578 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "standalone.boot.xml" (runtime-name: "standalone.boot.xml")
> 15:45:42,581 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "standalone.initial.xml" (runtime-name: "standalone.initial.xml")
> 15:45:42,724 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "standalone.last.xml" (runtime-name : "standalone.last.xml")
> 15:45:42,725 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "standalone.initial.xml" (runtime-name : "standalone.initial.xml")
> 15:45:42,726 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "standalone.boot.xml" (runtime-name : "standalone.boot.xml")
> 15:45:47,921 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment standalone.xml (runtime-name: standalone.xml) in 28ms
> 15:45:47,928 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "standalone.xml" (runtime-name: "standalone.xml")
> 15:45:47,930 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "standalone.v1.xml" (runtime-name: "standalone.v1.xml")
> 15:45:47,982 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment standalone.last.xml (runtime-name: standalone.last.xml) in 55ms
> 15:45:47,984 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "standalone.last.xml" (runtime-name: "standalone.last.xml")
> 15:45:48,059 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "standalone.last.xml" with deployment "standalone.last.xml"
> 15:45:48,060 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "standalone.v1.xml" (runtime-name : "standalone.v1.xml")
> 15:45:48,060 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "standalone.xml" with deployment "standalone.xml"
> 15:45:53,233 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment standalone.xml (runtime-name: standalone.xml) in 13ms
> 15:45:53,236 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "standalone.v2.xml" (runtime-name: "standalone.v2.xml")
> 15:45:53,237 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "standalone.xml" (runtime-name: "standalone.xml")
> 15:45:53,249 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment standalone.last.xml (runtime-name: standalone.last.xml) in 15ms
> 15:45:53,252 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "standalone.last.xml" (runtime-name: "standalone.last.xml")
> 15:45:53,340 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "standalone.last.xml" with deployment "standalone.last.xml"
> 15:45:53,341 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "standalone.v2.xml" (runtime-name : "standalone.v2.xml")
> 15:45:53,342 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "standalone.xml" with deployment "standalone.xml"{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-288) Kiali - Istio Checker to 0.8.0
by Matt Mahoney (JIRA)
[ https://issues.jboss.org/browse/SWSQE-288?page=com.atlassian.jira.plugin.... ]
Matt Mahoney commented on SWSQE-288:
------------------------------------
Teaming w/ Sunil. Script is working more reliably now. There may be some corner cases that we need to fix. Please comment here if you encounter any issues.
Downstream Istio deploy w/ Kial checker job ex: [http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-Downstream...
|http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-Downstream/104/console]
> Kiali - Istio Checker to 0.8.0
> ------------------------------
>
> Key: SWSQE-288
> URL: https://issues.jboss.org/browse/SWSQE-288
> Project: Kiali QE
> Issue Type: Sub-task
> Reporter: Hayk Hovsepyan
> Assignee: Sunil kondkar
> Priority: Blocker
>
> We have a job http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-Istio-Checker
> which checks Istio installation on OC. It works with 0.7.1 Istio.
> Main jenkins pipeline is switched to Istio 0.8.0 already.
> TODO
> Update this job and the script to support Istio 0.8.0 version pods which are:
> grafana-cd99bf478-2k9zj 1/1 Running 0 19m
> istio-citadel-ff5696f6f-6m8rv 1/1 Running 0 19m
> istio-cleanup-old-ca-qmd7k 0/1 Completed 0 19m
> istio-egressgateway-58d98d898c-4qhx9 0/1 CrashLoopBackOff 7 19m
> istio-ingressgateway-6bc7c7c4bc-867sz 0/1 CrashLoopBackOff 7 19m
> istio-mixer-post-install-kjhhk 0/1 Completed 0 19m
> istio-pilot-6c5c6b586c-gq6gt 2/2 Running 0 19m
> istio-policy-5c7fbb4b9f-j2jjd 2/2 Running 0 19m
> istio-sidecar-injector-dbd67c88d-ffkgm 1/1 Running 0 19m
> istio-statsd-prom-bridge-6dbb7dcc7f-fcl8f 1/1 Running 0 19m
> istio-telemetry-54b5bf4847-5wq78 2/2 Running 0 19m
> istio-tracing-67dbb5b89f-l52vk 1/1 Running 0 19m
> prometheus-586d95b8d9-dw9xl 1/1 Running 0 19m
> servicegraph-6d86dfc6cb-25qtp 1/1 Running 1 19m
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-288) Kiali - Istio Checker to 0.8.0
by Matt Mahoney (JIRA)
[ https://issues.jboss.org/browse/SWSQE-288?page=com.atlassian.jira.plugin.... ]
Matt Mahoney edited comment on SWSQE-288 at 6/25/18 4:54 PM:
-------------------------------------------------------------
Teaming w/ Sunil. Script is working more reliably now. There may be some corner cases that we need to fix. Please comment here if you encounter any issues.
Downstream Istio deploy w/ Kial checker job ex: http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-Downstream...
was (Author: mmahoney):
Teaming w/ Sunil. Script is working more reliably now. There may be some corner cases that we need to fix. Please comment here if you encounter any issues.
Downstream Istio deploy w/ Kial checker job ex: [http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-Downstream...
|http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-Downstream/104/console]
> Kiali - Istio Checker to 0.8.0
> ------------------------------
>
> Key: SWSQE-288
> URL: https://issues.jboss.org/browse/SWSQE-288
> Project: Kiali QE
> Issue Type: Sub-task
> Reporter: Hayk Hovsepyan
> Assignee: Sunil kondkar
> Priority: Blocker
>
> We have a job http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-Istio-Checker
> which checks Istio installation on OC. It works with 0.7.1 Istio.
> Main jenkins pipeline is switched to Istio 0.8.0 already.
> TODO
> Update this job and the script to support Istio 0.8.0 version pods which are:
> grafana-cd99bf478-2k9zj 1/1 Running 0 19m
> istio-citadel-ff5696f6f-6m8rv 1/1 Running 0 19m
> istio-cleanup-old-ca-qmd7k 0/1 Completed 0 19m
> istio-egressgateway-58d98d898c-4qhx9 0/1 CrashLoopBackOff 7 19m
> istio-ingressgateway-6bc7c7c4bc-867sz 0/1 CrashLoopBackOff 7 19m
> istio-mixer-post-install-kjhhk 0/1 Completed 0 19m
> istio-pilot-6c5c6b586c-gq6gt 2/2 Running 0 19m
> istio-policy-5c7fbb4b9f-j2jjd 2/2 Running 0 19m
> istio-sidecar-injector-dbd67c88d-ffkgm 1/1 Running 0 19m
> istio-statsd-prom-bridge-6dbb7dcc7f-fcl8f 1/1 Running 0 19m
> istio-telemetry-54b5bf4847-5wq78 2/2 Running 0 19m
> istio-tracing-67dbb5b89f-l52vk 1/1 Running 0 19m
> prometheus-586d95b8d9-dw9xl 1/1 Running 0 19m
> servicegraph-6d86dfc6cb-25qtp 1/1 Running 1 19m
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar commented on JGRP-2253:
--------------------------------------
In FD_SOCK,
startServerSocket() - Here we have an option to specify a start_port and and a port_range. If the specified start_port is already in use, we are trying up to the specified port_range to create the socket address.
Why we are not doing the same during setupPingSocket() ?
When an application specifies client_bind_port, Why don't FD_SOCK consider the port_range if the specified port is unavailable similar to startServerSocket()?
I have turned on debug logs of FD_SOCK and i was able to see that,
2018-06-25 15:01:15.067 DEBUG 6170 --- [FD_SOCK pinger-14,xx-SKS-test_SJX_210620181404_XSJ,ip-xx-xx-xx-xx-60384] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xx-xx-60384: failed connecting to ip-XX-xxx-xxx-47443: Address already in use (Bind failed)
In AWS environment's , it is not a good practice to define a wide range of inbound open ports. We are more comfortable to define a smaller set of port range as allowed inbound ports for an EC2 instance.
The above may not be a solution for the AWS EC2 termination but it is really good to have. I think, as you have mentioned, termination on EC2/AWS may not be closing the socket. Because I have removed my client_bind_port and opened EC2 security group rules to allow any inbound ports for testing purpose but FD_SOCK was still not working as expected. and the DEBUG/TRACE logs were clean with no issues
Thanks,
Sibin
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years