[JBoss JIRA] (WFLY-11374) Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
by Srinivas ev (Jira)
[ https://issues.jboss.org/browse/WFLY-11374?page=com.atlassian.jira.plugin... ]
Srinivas ev commented on WFLY-11374:
------------------------------------
Hi [~mnovak], it worked. Start and stop is done as you suggested, master is able to announce the backup.
-- start master--
./standalone.sh -c standalone-full-ha.xml -b xxx.xxx.xxx.xxx -bmanagement xxx.xxx.xxx.xxx -Djboss.bind.address.private=xxx.xxx.xxx.xxx -Djboss.server.default.config=$JBOSS_CONFIG -Djboss.server.log.dir=/var/log/myproject/serverlogs -DPROJECT_CONFIG_DIR=/opt/myproject/LIVEQ/conf -DPROJECT_DEPLOYMENT_DIR=/opt/myproject/LIVEQ/wildfly/standalone/deployments -DPROJECT_JDK_HOME=/usr/lib/jvm/java-1.8.0-openjdk -DMYPROJECT_HOME=/opt/myproject/LIVEQ/ -u 231.73.74.75 -Djboss.messaging.group.address=231.73.74.75 -Djboss.messaging.group.port=9855 -Djboss.socket.binding.port-offset=4000 -Djboss.node.name=myperf3-LIVEQ -Djboss.hostname=myperf3 -DMYPROJECT_BIN=/opt/myproject/LIVEQ/bin -Djboss.trace.log.dir=/var/log/myproject/traces -Djboss.logs.log.dir=/var/log/myproject/logs
kill -15 28425
./jboss-cli.sh -c --controller=135.250.138.170:13990 command=:shutdown --user=admin --password=admin@123
2018/11/29 15:45:36,713+05:30 INFO [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-netty-threads-2140640689)) AMQ221024: Backup server ActiveMQServerImpl::serverUUID=eb0308d8-f3a8-11e8-ad94-3dbc7a897972 is synchronized with live-server.
2018/11/29 15:45:38,037+05:30 INFO [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@67042056-570860242)) AMQ221031: backup announced
> Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
> ------------------------------------------------------------------------------
>
> Key: WFLY-11374
> URL: https://issues.jboss.org/browse/WFLY-11374
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: active standalone full ha.xml, master and slave log samples on startup.txt, master restart.txt, master shutdown.txt, master-server-linux.log, master-server-windows.log, master.xml, rotateserver_active.log, rotateserver_active.log, rotateserver_backup.log, rotateserver_slave.log, slave standalone full ha.xml, slave-server-linux.log, slave-server-windows.log, slave.xml
>
>
> I have 2 wildfly servers acting as artemis master and slave. I am expecting failback and replication and the related configurations are done for this to work.
> This is working as expected when I have the setup in Windows. Failing in linux RHEL 7.3 machine.
> master in standalone-full-ha.xml - refer master.xml
> slave in standalone-full-ha.xml - refer slave.xml
> In the startup script, I am passing all the values for placeholders of my server host ip's accordingly.
> Test scenario -
> 1. Bring master up.
> 2. Bring slave up.
> 3. slave will announce the backup. (AMQ221031: backup announced).
> 4. Make master down.
> 5. Replication is success.
> 6. Slave is acting as master/live.
> 7. Make master up.
> Issue - master is unable to announce the backup and starts normally as a standalone wildfly.
> This backup announcement works fine in windows and failover also works as expected.
> Please let me know if anything specific required along with this details.
> Artemis jar version - artemis-*****-1.1.0.wildfly-017.jar
> in path - /opt/aor/${my project}/wildfly/modules/system/layers/base/org/apache/activemq/artemis/main
> Few logs I found which may be impacting and I am not clear -
> 1.2018-11-21 14:28:07,238 TRACE [org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@38e819b6-2112524495)) Setting up bridge between TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-30 and ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-41], discoveryGroupConfiguration=null]: java.lang.Exception: trace
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge.<init>(ClusterConnectionBridge.java:129)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.createNewRecord(ClusterConnectionImpl.java:778)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.nodeUP(ClusterConnectionImpl.java:698)
> at org.apache.activemq.artemis.core.client.impl.Topology$1.run(Topology.java:264)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11439) Warning about JSF version 'NONE' is shown in logs
by Sultan Zhantemirov (Jira)
Sultan Zhantemirov created WFLY-11439:
-----------------------------------------
Summary: Warning about JSF version 'NONE' is shown in logs
Key: WFLY-11439
URL: https://issues.jboss.org/browse/WFLY-11439
Project: WildFly
Issue Type: Bug
Components: JSF
Affects Versions: 14.0.0.Beta2
Reporter: Sultan Zhantemirov
Assignee: Dmitrii Tikhomirov
Fix For: 15.0.0.Beta1
Attachments: clusterbench-ee7.ear
Following warning is shown in log upon server start:
{code}
2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead.
{code}
Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. Version 'NONE' is not specified anywhere, so this warning should not be present. From my point of view, it seems like I am trying set slot 'NONE' to be the default. But nothing like that is happening.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-2697) [DMN Designer] Improve readability of node labels
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-2697?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2697:
----------------------------------------
[~dadossan] [~tirelli] thought this might be a good candidate for you; as it involves _Stunner_ related code.
Edson would like the node text to be truncated and appended with "..." if the text is wider than the Node view itself. E.g. a Node with text "A long description" would become "A long de..." if it is wider than the Node view. If the node is made wider the text would change to "A long descrip..." etc until the node is wide enough to show all the text.
You can also take this opportunity to perhaps remove the font border (as we have no control over it in the UI and it's always black and obscures the fonts _real_ colour).
> [DMN Designer] Improve readability of node labels
> -------------------------------------------------
>
> Key: DROOLS-2697
> URL: https://issues.jboss.org/browse/DROOLS-2697
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Daniel José dos Santos
> Priority: Major
>
> Node names are bold text without background rectangle and hence _merge_ into the node SVG. It'd be nicer to change font to regular and provide a (white) background rectangle to improve readability. See https://github.com/kiegroup/kie-wb-common/pull/1929#pullrequestreview-133...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4228) Weld subsystem should declare a capability
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-4228?page=com.atlassian.jira.plugi... ]
Yeray Borges updated WFCORE-4228:
---------------------------------
Description:
This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
Specifically it was identified the following minor changes:
* -Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)-
* Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
WeldDeploymentMarker is consideated as part of Weld subsystem, so, we are not going to move it to wfcore
was:
This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
Specifically it was identified the following minor changes:
* -Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)-
* Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
> Weld subsystem should declare a capability
> ------------------------------------------
>
> Key: WFCORE-4228
> URL: https://issues.jboss.org/browse/WFCORE-4228
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
>
> This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
> Specifically it was identified the following minor changes:
> * -Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)-
> * Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
> WeldDeploymentMarker is consideated as part of Weld subsystem, so, we are not going to move it to wfcore
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4228) Weld subsystem should declare a capability
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-4228?page=com.atlassian.jira.plugi... ]
Yeray Borges updated WFCORE-4228:
---------------------------------
Description:
This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
Specifically it was identified the following minor changes:
* -Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)-
* Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
was:
This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
Specifically it was identified the following minor changes:
* Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)
* Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
> Weld subsystem should declare a capability
> ------------------------------------------
>
> Key: WFCORE-4228
> URL: https://issues.jboss.org/browse/WFCORE-4228
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
>
> This issue is filed to to track the required changes in wildfly-core to complete the work on WFLY-11186
> Specifically it was identified the following minor changes:
> * -Make WeldDeploymentMarker available on wildfly-server, where other there are other clases that serve a similar purposes (JPADeploymentMarker, EjbDeploymentMarker)-
> * Add a method signature that allow retrieve an optional capability API from CapabilityServiceSupport without throwing a checked exception. That can be useful when we need a capability API that it is optional for the demanding subsystem
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-10929) Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-10929?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFLY-10929:
--------------------------------------
Steps to Reproduce:
# unzip WildFly and start via ./bin/standalone.sh
# in CLI perform following operations:
{code}
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add(use-server-log=true)
deploy helloworld.war
reload
{code}
# Now try to access WildFly server:
{code}
# First against HTTP listener:
curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
# Check result in access log
# Now try against HTTPS listener:
curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
# Check result in access log
{code}
was:
# unzip WildFly and start via ./bin/standalone.sh
# in CLI perform following operations:
{code}
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-unescaped-characters-in-url,value=true)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=allow-unescaped-characters-in-url,value=true)
deploy helloworld.war
reload
{code}
# Now try to access WildFly server:
{code}
# First against HTTP listener:
curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
# Check result in access log
# Now try against HTTPS listener:
curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
# Check result in access log
{code}
> Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10929
> URL: https://issues.jboss.org/browse/WFLY-10929
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: helloworld.war
>
>
> Since the time of {{EAP7.1.1.CP}} there is a possibility to allow unescaped characters in URL requests from clients to server. This was allowed first by setting {{org.wildfly.undertow.ALLOW_UNESCAPED_CHARACTERS_IN_URL=true}} system property introduced by UNDERTOW-1185. Now we have a new attribute for this in Wildfly in AJP, HTTP and HTTPS listeners {{allow-unescaped-characters-in-url}}.
> However this does not seem to work correctly. There have been some fixes for AJP listener already UNDERTOW-1386, UNDERTOW-1386 and UNDERTOW-1399 (the last one not included in WildFly {{14.0.0.Beta2}} yet). However HTTP/HTTPS listener seems to be broken too.
> When HTTP request with unescaped characters is performed against server:
> {code}
> curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null
> {code}
> we get 200 OK HTTP response, although the result in access log looks like:
> {code:title=HTTP actual result}
> 127.0.0.1 - - [27/Aug/2018:09:17:39 +0200] "GET /helloworld/íê¸ì´ë¦
> _test.html?param=íê¸ì´ë¦
> _ahoy HTTP/1.1" 200 950
> {code}
> but we expect following:
> {code:title=HTTP expected result}
> 127.0.0.1 - - [27/Aug/2018:08:40:47 +0200] "GET /helloworld/한글이름_test.html?param=한글이름_ahoy HTTP/1.1" 200 950
> {code}
> Slightly different problem seems to be also for HTTPS listener. When we perform HTTPS request against WildFly:
> {code}
> curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure
> {code}
> we receive 404 Not Found HTTP response and following record in access.log:
> {code:HTTPS actual result}
> 127.0.0.1 - - [27/Aug/2018:09:18:37 +0200] "GET /helloworld/￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_test.html?param=￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_ahoy HTTP/2.0" 404 68
> {code}
> however expected result should be similar to what we expect for HTTP, I guess.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month