[JBoss JIRA] (WFWIP-39) Regression in JMS bridge with network failures tests
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-39?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak resolved WFWIP-39.
---------------------------------
Resolution: Done
Marking as resolved based on related jira ENTMQBR-1616 and comment:
https://issues.jboss.org/browse/ENTMQBR-1616?focusedCommentId=13610958&pa...
Also this test is no longer failing in our CI runs.
> Regression in JMS bridge with network failures tests
> ----------------------------------------------------
>
> Key: WFWIP-39
> URL: https://issues.jboss.org/browse/WFWIP-39
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq
> Attachments: org.jboss.qa.hornetq.test.bridges.NetworkFailuresJMSBridgesTestCase.zip
>
>
> *Scenario*
> Node A and B are started. JMS bridge with {{once and only once}} delivery and 1 reconnect attempt is deployed on node A. Producer starts sending mix of normal and large messages to InQueue on node A. Jms bridge resends messages from A's InQueue to B's OutQueue. During this time short network failure sequence (network goes down and then up) is executed twice. Receiver receives messages from OutQueue(also from node A). After that, network stays disconnected. Another receiver receives remaining messages from A's InQueue.
> {noformat:title=Jms Bridge}
> <jms-bridge name="myBridge" module="org.apache.activemq.artemis" quality-of-service="ONCE_AND_ONLY_ONCE" failure-retry-interval="1000" max-retries="1" max-batch-size="10" max-batch-time="100" add-messageID-in-header="true">
> <source connection-factory="java:/ConnectionFactory" destination="jms/queue/InQueue"/>
> <target connection-factory="jms/BridgeConnectionFactory" destination="jms/queue/OutQueue">
> <target-context>
> <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
> <property name="java.naming.provider.url" value="http-remoting://127.0.0.1:9080"/>
> </target-context>
> </target>
> </jms-bridge>
> {noformat}
> *Issue*
> * node A's InQueue and node B's OutQueue is empty
> * There are no prepared transactions on node A
> * some messages *are missing* after test (multiply of 10, which is number of messages in one transaction)
> * this scenario fails *intermittently*
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
> Logs are attached.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-72) Critical IO Error ... when starting Artemis with HA JDBC store
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-72?page=com.atlassian.jira.plugin.s... ]
Erich Duda updated WFWIP-72:
----------------------------
Summary: Critical IO Error ... when starting Artemis with HA JDBC store (was: Critical IO Error ... when starting Artemis in colocated topology with HA JDBC store)
> Critical IO Error ... when starting Artemis with HA JDBC store
> --------------------------------------------------------------
>
> Key: WFWIP-72
> URL: https://issues.jboss.org/browse/WFWIP-72
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Attachments: log-node-1.zip
>
>
> One of the servers in collocated HA topology with JDBC store can fail on critical IO exception and stop itself.
> This was hit on Artemis 1.5.5.012 and WF: https://github.com/jmesnil/wildfly - WFLY-9513_messaging_jdbc_HA_shared-store branch.
> Test scenario:
> * Start 2 WF/EAP servers in collocated topology with Artemis HA JDBC store
> * Start client which are sending and consuming messages to/from queue from 1st server
> Result:
> There is intermittent failure when client start to send/receive messages on 1st server. 1st fails on Critical IO Error with exception:
> {code}
> 10:19:27,965 WARN [org.apache.activemq.artemis.journal] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7de7cbe3)) AMQ142021: Error on IO callback, null
> 10:19:27,965 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@7de7cbe3)) AMQ222010: Critical IO Error, shutting down the server. file=org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile@407c5d8f, message=Error writing to JDBC file.: java.lang.NullPointerException
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.internalWrite(JDBCSequentialFile.java:161) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.internalWrite(JDBCSequentialFile.java:186) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.lambda$scheduleWrite$1(JDBCSequentialFile.java:197) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
> NPE happens at {{JDBCSequentialFile.internalWrite}} line 161:
> {code}
> private synchronized int internalWrite(byte[] data, IOCallback callback) {
> try {
> open();
> 161 synchronized (writeLock) { <-- NPE is thrown here
> ...
> {code}
> .
> Attaching logs from the test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2825) Drools @Expires is not working with x seconds 7.4.1 Final Drools version
by Srinivas ev (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2825?page=com.atlassian.jira.plugi... ]
Srinivas ev edited comment on DROOLS-2825 at 8/13/18 1:02 AM:
--------------------------------------------------------------
Hi Team, is there any update ?
Making it as the blocker as my application is consuming lot of memory.
was (Author: ev.srinivas):
Hi Team, is there any update ?
> Drools @Expires is not working with x seconds 7.4.1 Final Drools version
> ------------------------------------------------------------------------
>
> Key: DROOLS-2825
> URL: https://issues.jboss.org/browse/DROOLS-2825
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.4.1.Final
> Reporter: Srinivas ev
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 7.4.1.Final
>
> Attachments: EvictionTest.zip, heap.PNG
>
>
> Attached reproducer. Please check once,
> I inserted 5 Fact POJO's. It should have deleted after 200s based on declaration in the rule file.
> declare Fact
> @role( event )
> @expires(200s)
> end
> Heap dump shows the 5 entries even after I took the heap dump after 10 minutes. Please let me know regarding this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2825) Drools @Expires is not working with x seconds 7.4.1 Final Drools version
by Srinivas ev (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2825?page=com.atlassian.jira.plugi... ]
Srinivas ev commented on DROOLS-2825:
-------------------------------------
Hi Team, is there any update ?
> Drools @Expires is not working with x seconds 7.4.1 Final Drools version
> ------------------------------------------------------------------------
>
> Key: DROOLS-2825
> URL: https://issues.jboss.org/browse/DROOLS-2825
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.4.1.Final
> Reporter: Srinivas ev
> Assignee: Mario Fusco
> Fix For: 7.4.1.Final
>
> Attachments: EvictionTest.zip, heap.PNG
>
>
> Attached reproducer. Please check once,
> I inserted 5 Fact POJO's. It should have deleted after 200s based on declaration in the rule file.
> declare Fact
> @role( event )
> @expires(200s)
> end
> Heap dump shows the 5 entries even after I took the heap dump after 10 minutes. Please let me know regarding this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2825) Drools @Expires is not working with x seconds 7.4.1 Final Drools version
by Srinivas ev (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2825?page=com.atlassian.jira.plugi... ]
Srinivas ev updated DROOLS-2825:
--------------------------------
Priority: Blocker (was: Major)
> Drools @Expires is not working with x seconds 7.4.1 Final Drools version
> ------------------------------------------------------------------------
>
> Key: DROOLS-2825
> URL: https://issues.jboss.org/browse/DROOLS-2825
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.4.1.Final
> Reporter: Srinivas ev
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 7.4.1.Final
>
> Attachments: EvictionTest.zip, heap.PNG
>
>
> Attached reproducer. Please check once,
> I inserted 5 Fact POJO's. It should have deleted after 200s based on declaration in the rule file.
> declare Fact
> @role( event )
> @expires(200s)
> end
> Heap dump shows the 5 entries even after I took the heap dump after 10 minutes. Please let me know regarding this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10825) Upgrade to Hibernate Validator 6.0.12.Final
by Guillaume Smet (JIRA)
[ https://issues.jboss.org/browse/WFLY-10825?page=com.atlassian.jira.plugin... ]
Guillaume Smet commented on WFLY-10825:
---------------------------------------
[~jamezp] We run the Bean Validation TCK as part of our standard test suite: standalone and included into WildFly.
This is the short story. For this issue, the story is unfortunately longer: when Apache BVal reported some portability issues a few months ago, we unfortunately introduced a portability issue in the TCK which remained unnoticed because of the very fix we reverted (we removed annotations from a bean as an implemented interface was already defining the constraint annotations -> the bean ended up without any BV annotations except on the interface -> this is exactly the issue we wanted to fix with the initial (slow) patch we just reverted). I fixed the issue in the TCK by adding an annotation (as recommended by the spec for portability) and pushed a new version. I also informed Oracle they should upgrade the TCK in the EE TCK to 2.0.4.Final.
So we should be safe on this matter.
> Upgrade to Hibernate Validator 6.0.12.Final
> -------------------------------------------
>
> Key: WFLY-10825
> URL: https://issues.jboss.org/browse/WFLY-10825
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Bean Validation
> Reporter: Guillaume Smet
> Assignee: Guillaume Smet
> Fix For: 14.0.0.CR1
>
>
> The changelog is here: https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HV%20AND%20fi... .
> The only changes affecting WildFly are:
> * https://hibernate.atlassian.net/browse/HV-1645 - CDI integration change
> * https://hibernate.atlassian.net/browse/HV-1643 - minor Russian translation fix
> the rest are infrastructure changes to run the integration test with latest WF 14 Beta1 (and thus allowing us to run them again with JDK 11) and a fix to our dependencies with JDK 11 (which doesn't affect WF at all).
> The reason of this upgrade is specifically the CDI integration change. It reverts the behavior to what was done prior to 6.0.10.Final due to a regression in the startup time of the CDI applications reported by the Open Liberty team.
> As WF 13 was released with HV 6.0.10.Final, it could potentially change the behavior for people having used the EE8 preview mode. This does not concern EAP as the behavior of HV 6.0.12.Final is the same as the version in previous EAP.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-98) MP Health is not available in domain mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFWIP-98?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on WFWIP-98:
---------------------------------------
+1 [~jmesnil] re: next iteration and +1 [~rsvoboda] about stating that in the proposal.
The DMR check operation will work fine in a domain (even if we don't formally support it.) Supporting accessing a /health endpoint on a domain server management interface is a bad idea. If in the future we allow configuring the endpoint on the undertow subsystem then that would work fine too.
> MP Health is not available in domain mode
> -----------------------------------------
>
> Key: WFWIP-98
> URL: https://issues.jboss.org/browse/WFWIP-98
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> MP Health is not available in domain mode.
> Analysis is not saying that domain is out of scope, EAP7 RFE is not explicit about this either.
> We may resolve this just by making it explicit, that MP health is just fo standalone for now.
> For domain we should at least have a plan what to do and how
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-96) MP Health - security enabled, no user yed added, user get info about adding user to access web console, HTTP code is 200, should be 500
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFWIP-96?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on WFWIP-96:
---------------------------------------
As to the response page content, unless it's really simple I'd rather we slightly edit the current one to make it applicable to any request that hits management authentication as opposed to adding an entire new set of content and logic to control which is used.
[~yersan] FYI. Either way there will be a tweak to eap-ization for this.
> MP Health - security enabled, no user yed added, user get info about adding user to access web console, HTTP code is 200, should be 500
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-96
> URL: https://issues.jboss.org/browse/WFWIP-96
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
> Note: I didn't add user via {{bin/add-user.sh}}
> When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
> {code}
> <h3>Your WildFly Application Server is running.</h3>
> <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
> to access the admin console.</p>
> <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
> your WildFly installation and enter the requested information.</p>
> {code}
> Can /health endpoint get customized response in case no mgmt user is defined on server side ?
> Current response can be little confusing if user is not yet so familiar with WildFly.
> I marked this as minor bug.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months