[JBoss JIRA] (WFWIP-27) [Artemis 2.x Upgrade] Failover does not work with HTTP connectors/acceptors
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFWIP-27?page=com.atlassian.jira.plugin.s... ]
Martyn Taylor commented on WFWIP-27:
------------------------------------
[~jmesnil] I can't say for sure as I don't know why the original change was made. I don't believe though that we should be clearing the callbacks on a stop. We'll revert the change and run the Artemis suite to see if it uncovers the original problem. [~brian.stansberry] Thanks again for the investigation.
> [Artemis 2.x Upgrade] Failover does not work with HTTP connectors/acceptors
> ---------------------------------------------------------------------------
>
> Key: WFWIP-27
> URL: https://issues.jboss.org/browse/WFWIP-27
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: clients.log, server1.log, server2.log, standalone-full-ha.xml, standalone-full-ha.xml, test.log
>
>
> Failover does not work with HTTP connectors/acceptors.
> *Scenario:*
> # There are two Wildfly servers configured as Live-Backup pair
> # There is one JMS producer and one JMS receiver which sends/receives messages
> # Live server is several times killed and restarted.
> *Expectation:* Always when the Live server is killed or restarted, clients do failover or failback.
> *Reality*: Sometimes happens that clients don't do failover.
> *Users impact:* One of basics feature of HA, failover, does not work properly.
> *Blocker* priority was set because this is regression against previous releases of Wildfly.
> *Detail description of issue*
> In the trace logs it can be seen that clients send HTTP handshake request to active backup, but the handshake fails. All checks (and logs) say that the backup is active in this time period. I tried to run the test with Netty connectors/acceptors and I didn't see this issue.
> {code:title=Backup log}
> 07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=55, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
> 07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=56, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
> 07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485068, b=2147485067]
> 07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485076, b=2147485075]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484450, b=2147484449]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485072, b=2147485071]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484454, b=2147484453]
> 07:52:47,866 WARN [org.apache.activemq.artemis.core.client] (activemq-discovery-group-thread-dg-group1) AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID=0dee81c9-2d9d-11e8-ba3f-cc3d825f79a4
> 07:52:47,867 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221007: Server is now live
> {code}
> {code:title=Clients log}
> 07:52:49,274 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
> 07:52:49,274 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=8080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1081] Trying backup config = TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=9080&host=localhost
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:447] Connector NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] using native epoll
> 07:52:49,275 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET HTTP/1.1
> host: localhost
> upgrade: activemq-remoting
> connection: upgrade
> activemqServerName: default
> httpUpgradeEndpoint: acceptor
> Sec-ActiveMQRemoting-Key: QWV3bCfgh75NjWH3pZV5Ew==
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:601] AMQ211002: Started EPOLL Netty Connector version 4.1.16.Final to localhost:9080
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
> 07:52:49,276 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET HTTP/1.1
> host: localhost
> upgrade: activemq-remoting
> connection: upgrade
> activemqServerName: default
> httpUpgradeEndpoint: acceptor
> Sec-ActiveMQRemoting-Key: P9xBwRk1eZP5QjDWjqYuIg==
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
> Content-Length: 2426
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Thu, 22 Mar 2018 06:52:49 GMT
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
> Content-Length: 2426
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Thu, 22 Mar 2018 06:52:49 GMT
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
> 07:52:49,277 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFWIP-60) smallrye-config: Consider logging a message when properties with same key and ordinal are present
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFWIP-60?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil commented on WFWIP-60:
----------------------------------
This might be out of scope of the initial integration but I plan afterwards to add runtime operations to help on the "detective work" as you mention :)
In https://github.com/eclipse/ConfigJSR/issues/10#issuecomment-344881189, I proposed management operations to list the config source (according to their ordinal) as well as an operation to evaluate a property (and returned all its known value sorted by their config-source's ordinal)
> smallrye-config: Consider logging a message when properties with same key and ordinal are present
> -------------------------------------------------------------------------------------------------
>
> Key: WFWIP-60
> URL: https://issues.jboss.org/browse/WFWIP-60
> Project: WildFly WIP
> Issue Type: Enhancement
> Components: MP Config
> Reporter: Michal Jurc
> Assignee: Jeff Mesnil
>
> Consider a deployment with default {{microprofile-config.properties}}:
> {code}managementDefault=Default value from default microprofile-config.properties{code}
> Deployment is deployed on server with the following {{ConfigSource}} defined:
> {code}[standalone@localhost:9990 /] /subsystem=microprofile-config-smallrye/config-source=testdefault:read-resource
> {
> "outcome" => "success",
> "result" => {
> "class" => undefined,
> "dir" => undefined,
> "ordinal" => 100,
> "properties" => {"managementDefault" => "Value from WildFly microprofile-config-smallrye config-source"}
> }
> }
> {code}
> Property {{"managementDefault"}} is always resolved to {{"Value from WildFly microprofile-config-smallrye config-source"}} in deployment.
> It would be useful to log a {{WARN}} level message when there is conflict like this with a notification of {{ConfigSources}} to save detective work in real world scenarios.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2674) Save, reload and open a scenario
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2674?page=com.atlassian.jira.plugi... ]
Toni Rikkola closed DROOLS-2674.
--------------------------------
Resolution: Done
> Save, reload and open a scenario
> --------------------------------
>
> Key: DROOLS-2674
> URL: https://issues.jboss.org/browse/DROOLS-2674
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Juraj Soltes
> Assignee: Toni Rikkola
>
> As a business analyst I want to save a scenario so that all the data I fill in are stored and can be reloaded. ( over an empty asset file without the persistance )
> The task requires:
> * A copy&paste of the text editor modules in to drools-wb module list.
> * Setting the file extension for the simulation tests ( does not have to be final, we can change it later )
> * Renaming the classes to fit the simulation test terms
> * Change the model from String to ScenarioSimulationModel
> * Adding the modules in to the drools-wb -webapp
> * Adding the modules into the droolsjbpm-bootstrap pom.xml
> After the feature is done:
> * User can upload a file with the extension using the upload tool
> * User can see the file in the Project Asset List screen and open it
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFWIP-60) smallrye-config: Consider logging a message when properties with same key and ordinal are present
by Michal Jurc (JIRA)
Michal Jurc created WFWIP-60:
--------------------------------
Summary: smallrye-config: Consider logging a message when properties with same key and ordinal are present
Key: WFWIP-60
URL: https://issues.jboss.org/browse/WFWIP-60
Project: WildFly WIP
Issue Type: Enhancement
Components: MP Config
Reporter: Michal Jurc
Assignee: Jeff Mesnil
Consider a deployment with default {{microprofile-config.properties}}:
{code}managementDefault=Default value from default microprofile-config.properties{code}
Deployment is deployed on server with the following {{ConfigSource}} defined:
{code}[standalone@localhost:9990 /] /subsystem=microprofile-config-smallrye/config-source=testdefault:read-resource
{
"outcome" => "success",
"result" => {
"class" => undefined,
"dir" => undefined,
"ordinal" => 100,
"properties" => {"managementDefault" => "Value from WildFly microprofile-config-smallrye config-source"}
}
}
{code}
Property {{"managementDefault"}} is always resolved to {{"Value from WildFly microprofile-config-smallrye config-source"}} in deployment.
It would be useful to log a {{WARN}} level message when there is conflict like this with a notification of {{ConfigSources}} to save detective work in real world scenarios.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-345) Checker job to Istio 1.0.0
by Hayk Hovsepyan (JIRA)
Hayk Hovsepyan created SWSQE-345:
------------------------------------
Summary: Checker job to Istio 1.0.0
Key: SWSQE-345
URL: https://issues.jboss.org/browse/SWSQE-345
Project: Kiali QE
Issue Type: Sub-task
Reporter: Hayk Hovsepyan
Assignee: Michael Foley
Adjust checker job to support Istio 1.0.0.
Do not forget about bookinfo as well, it seems to be different in Istio 1.0.0
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-344) Bookinfo installation/starting for Istio 1.0.0
by Hayk Hovsepyan (JIRA)
Hayk Hovsepyan created SWSQE-344:
------------------------------------
Summary: Bookinfo installation/starting for Istio 1.0.0
Key: SWSQE-344
URL: https://issues.jboss.org/browse/SWSQE-344
Project: Kiali QE
Issue Type: Sub-task
Reporter: Hayk Hovsepyan
Assignee: Michael Foley
Bookinfo in Istio 1.0.0 differs from 0.8.0, so it needs investigation what is the difference in terms of installation/starting with Istio.
Adjust bookinfo installation/starting jenkins job.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-342) QE: Kiali move to Istio 1.0.0
by Hayk Hovsepyan (JIRA)
Hayk Hovsepyan created SWSQE-342:
------------------------------------
Summary: QE: Kiali move to Istio 1.0.0
Key: SWSQE-342
URL: https://issues.jboss.org/browse/SWSQE-342
Project: Kiali QE
Issue Type: Story
Reporter: Hayk Hovsepyan
Assignee: Michael Foley
Kiali is going to be moved on Istio 1.0.0, dev branch is created for that.
Early testing was completed from QE side.
We need several tasks on QE side to adjust Pipeline, Bookinfo installation, checker job...
This is umbrella task for Istio 1.0.0 moving.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFWIP-59) Enable CDI by default when MP Config usage is detected in the deployment
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-59?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda commented on WFWIP-59:
----------------------------------------
MP Config without CDI makes no sense, {{ConfigProvider.getConfig()}} way is pretty minor use case.
CDI annotations presence in MP Config apps can be questionable - e.g. pure servlet or JAX-RS case.
Java EE 7 enabled CDI by default, we should make it enabled by MP Config based deployments too.
https://blogs.oracle.com/theaquarium/default-cdi-enablement-in-java-ee-7
> Enable CDI by default when MP Config usage is detected in the deployment
> ------------------------------------------------------------------------
>
> Key: WFWIP-59
> URL: https://issues.jboss.org/browse/WFWIP-59
> Project: WildFly WIP
> Issue Type: Enhancement
> Components: MP Config
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Enable CDI by default when MP Config usage is detected in the deployment.
> Currently users are forced to add empty {{beans.xml}} to the deployment every time they want to use MP Config - e.g. in simple servlet scenario
> {code}
> @WebServlet("/")
> public class HelloServlet extends HttpServlet {
> @Inject
> @ConfigProperty(name = "port_number")
> Integer port;
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
> resp.getWriter().println("Value of port: " + port);
> }
> }
> {code}
> MP Config without CDI makes no sense to me. MP Config subsystem should be able to ensure CDI is enabled. CCing [~manovotn] [~brian.stansberry]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years