[JBoss JIRA] (WFCORE-2671) CLI Opertation 'load' for Elytron key-store does not correctly re-read keystore
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2671?page=com.atlassian.jira.plugi... ]
Yeray Borges reassigned WFCORE-2671:
------------------------------------
Assignee: Yeray Borges (was: Darran Lofthouse)
> CLI Opertation 'load' for Elytron key-store does not correctly re-read keystore
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2671
> URL: https://issues.jboss.org/browse/WFCORE-2671
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Yeray Borges
> Priority: Blocker
>
> When keystore (or cerficate in keystore) is changed during server runtime then CLI opertation {{load}} can be used for {{/subsystem=elytron/key-store=...}} to re-reading this keystore in server. However after calling this operation server still works with original keystore/certificate. Then CLI reads current keystore correctly, but in case when ssl-context which uses that key-store is used then original keystore is still used by server. Reload of server is required to correctly re-read the new keystore. See Steps to Reproduce for more details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2162:
---------------------------
Fix Version/s: 4.0.3
(was: 4.0.2)
> Failed to send broadcast when opening the connection
> ----------------------------------------------------
>
> Key: JGRP-2162
> URL: https://issues.jboss.org/browse/JGRP-2162
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 4.0.3
>
> Attachments: TcpNio2McastTest.java, infinispan_2.log.gz
>
>
> IRC discussion:
> {quote}
> bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
> <bela_> rvansa: reproducible?
> <rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
> <rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
> <bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
> <bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
> <rvansa> bela_: I don't think it should go over the limit
> <rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
> <rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
> {quote}
> I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]):
> {code:xml}
> <TCPPING async_discovery="true" initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800]}" port_range="0"/>
> {code}
> This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore).
> Note that increasing the timeout in request options does not help.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if a JMS message is sent from an MDB
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.... ]
Scott Van Wart updated WFLY-8217:
---------------------------------
Priority: Minor (was: Major)
> ActiveMQ leaks connections if a JMS message is sent from an MDB
> ---------------------------------------------------------------
>
> Key: WFLY-8217
> URL: https://issues.jboss.org/browse/WFLY-8217
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Running on Windows 10. Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
> Reporter: Scott Van Wart
> Assignee: Jeff Mesnil
> Priority: Minor
> Attachments: leak.zip, leak.zip, log.txt, log.txt, server.log
>
>
> If an MDB causes a JMS message to be sent during the call to onMessage(), ActiveMQ won't close its connection. I'm using JMS2 through an @Inject'ed JMSContext. My sample project is an EAR with an EJB JAR (containing a service and an MDB) and a JAX-RS endpoint (entry point for the test).
> 1) Build the EAR
> 2) Run wildfly with the standalone-full.xml configuration:
> {{standalone.bat --server-config=standalone-full.xml}}
> 3) Enable debug and error reporting for leaked connections with ActiveMQ/CCM:
> {{jboss-cli.bat -c}}
> {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=debug,value=true)}}
> {{/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=error,value=true)}}
> 4) Deploy the EAR.
> 5) Access http://localhost:8080/leak-web/rest/test?message=Hi
> The REST endpoint will send a message to the test topic (Defined in leak-ejb/src/main/java/test/mdb/TestTopic.java). TestTopicListener (in the same package as TestTopic) will receive the message and send a second message to the topic. Upon returning from TestTopicListener.onMessage(), the message is sent, but this shows up in the logs
> (see attached log.txt)
> I have no idea why JIRA attached each file twice.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8584) Unite Jackson behavior with other application servers for JAX-RS client
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-8584?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-8584:
-------------------------------------
Assignee: Weinan Li (was: Alessio Soldano)
> Unite Jackson behavior with other application servers for JAX-RS client
> -----------------------------------------------------------------------
>
> Key: WFLY-8584
> URL: https://issues.jboss.org/browse/WFLY-8584
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Pavel Pscheidl
> Assignee: Weinan Li
> Priority: Optional
>
> Currently, WildFly's behaviour is not aligned with with other application servers when JSON is deserialized into POJOs.
> h3. Unrecognized properties
> UnrecognizedPropertyException - The property is in the JSON, but not in the POJO. Other application servers ignore such properties
> {code:java}
> public class SomeDTO{
> private String property1;
> //Getters and setters
> }
> {code}
> {code:json}
> {
> "property1": "This one will not cause any troubles",
> "property2": "This one causes UnrecognizedPropertyException istead of being ignored"
> }
> {code}
> To fix this behavior, provided dependency on arbitraty Jackson version must be present in the project and @JsonIgnoreProperties annotation must be used.
> {code:java}
> @JsonIgnoreProperties(ignoreUnknown = true)
> public class SomeDTO {
> private String property1;
> //Getters and setters
> }
> {code}
> Programs without @JsonIgnoreProperties annotation are very fragile in production (the API contract may change (one moje property added) and the whole client goes down.
> h3. Property naming
> Property naming - POJO attribute naming are what matters elsewhere. In WildFly, @JsonProperty annotation must be used to tell Jackson the correct name of the POJO, since all the attribute names are for some reason converted into lower case. This also results in UnrecognizedPropertyException.
> This code will not work
> {code:java}
> public class Rates {
> private BigDecimal AUD;
> }
> {code}
> for this JSON:
> {code:json}
> {
> "AUD": 1.334523
> }
> {code}
> The resulting error is:
> {code:text}
> Unrecognized field "AUD" (class entity.Rates), not marked as ignorable (31 known properties: "aud",....
> {code}
> However, when @JsonProperty annotation is used on the field, things suddenly work:
> {code:java}
> public class Rates {
> @JsonProperty("AUD")
> private BigDecimal AUD;
> }
> {code}
> Jackson annotations provided dependency must be used almost every time to ensure application stability in production. This is less problematic nowadays, when near every application server contains Jackson. When Java EE 8 comes, this will be even more controversial:
> {code:xml}
> <dependency>
> <groupId>com.fasterxml.jackson.core</groupId>
> <artifactId>jackson-annotations</artifactId>
> <version>2.8.6</version>
> <scope>provided</scope>
> </dependency>
> {code}
> h3. Behavior of other application servers
> There is a sample JAX-RS client/sever application [on GitHub|https://github.com/Pscheidl/jax-rs-application-server-test]. When deployed without Jackson annotations, it works perfectly in:
> # Glassfish 4
> # Payara 171 /obviously, should be the same as Glassfish/
> # TomEE
> # Websphere Liberty
> Other AS were not tested.
> Please note, there is also the problem with Resteasy not creating HTTP pools, causing problems when calling WebTarget conncurrently. The sample application may cause errors in WildFly when called concurrently.
> h3. Proposal summary
> I propose adopting behavior of other application servers - no Jackson annotations required by default. Missing properties being ignored by default, as well as correcting the property name resolution.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2167) Highest seqno is not resent nor recorded on receivers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2167?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2167:
--------------------------------
{{Table.hr}} is not set because we receive only the seqno but not the message itself. If we set {{hr}} to (say) 500, then that would assume message number 500 has been received, and it won't get retransmitted. I don't want to change this logic as the change would be quite involved.
However, the last seqno is only resent by a member P when P is not sending any further messages (independent though of other members sending or receiving messages), so increasing {{resend_last_seqno_max_times}} will reduce (not eliminate) the chances of a last-multicast-dropped scenario. I suggest this as a workaround for now.
> Highest seqno is not resent nor recorded on receivers
> -----------------------------------------------------
>
> Key: JGRP-2167
> URL: https://issues.jboss.org/browse/JGRP-2167
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 4.0.2
>
>
> I am investigating an issue in a stress test which leads me to a situation where in a TCP-based configuration a {{GMS[VIEW]}} is broadcast to all nodes, but it is not received by some of them. Soon after that there's a {{NAKACK2.HIGHEST_SEQNO}} that causes the node that is missing the last seqno to resend it, but the retransmit is not received either. There are no further retries, and generally no NAKACK2 activity until about 30 seconds later (when another node leaves after some timeout in the test).
> The receiver does not keep asking for retransmissions until it gets them, but it seems that {{NAKACK2.handleHighestSeqno}} doesn't update {{Table.hr}} (not sure if having highest received set to non-received msg would be legal, though).
> The sender uses default value {{NAKACK2.resend_last_seqno_max_times=1}}, and as there are no further mcast messages, the highest sent seqno does not change on sender.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2167) Highest seqno is not resent nor recorded on receivers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2167?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2167.
----------------------------
Resolution: Won't Fix
> Highest seqno is not resent nor recorded on receivers
> -----------------------------------------------------
>
> Key: JGRP-2167
> URL: https://issues.jboss.org/browse/JGRP-2167
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 4.0.2
>
>
> I am investigating an issue in a stress test which leads me to a situation where in a TCP-based configuration a {{GMS[VIEW]}} is broadcast to all nodes, but it is not received by some of them. Soon after that there's a {{NAKACK2.HIGHEST_SEQNO}} that causes the node that is missing the last seqno to resend it, but the retransmit is not received either. There are no further retries, and generally no NAKACK2 activity until about 30 seconds later (when another node leaves after some timeout in the test).
> The receiver does not keep asking for retransmissions until it gets them, but it seems that {{NAKACK2.handleHighestSeqno}} doesn't update {{Table.hr}} (not sure if having highest received set to non-received msg would be legal, though).
> The sender uses default value {{NAKACK2.resend_last_seqno_max_times=1}}, and as there are no further mcast messages, the highest sent seqno does not change on sender.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8586) Warning "WFLYRS0015: No Servlet declaration found for JAX-RS application." raised for non-JAX-RS submodules
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-8586?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated WFLY-8586:
----------------------------------
Affects Version/s: 11.0.0.Alpha1
(was: 11.0.0.Beta1)
> Warning "WFLYRS0015: No Servlet declaration found for JAX-RS application." raised for non-JAX-RS submodules
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8586
> URL: https://issues.jboss.org/browse/WFLY-8586
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 11.0.0.Alpha1
> Reporter: Frank Langelage
> Assignee: Alessio Soldano
> Fix For: 11.0.0.Beta1
>
>
> When deploying my application (ear with a couple of jar and war files) on Wildfly 11.0.0.Beta1-SNAPSHOT I get warnings like this one for all the war files:
> {noformat}
> WARN [org.jboss.as.jaxrs#deploy] WFLYRS0015: No Servlet declaration found for JAX-RS application. In ws-common.war either provide a class that extends javax.ws.rs.core.Application or declare a servlet class in web.xml.
> {noformat}
> When deploying the same ear file on a Wildfly 10.1. this warning message does not appear.
> Those war files raising the warnings do not contain RESTful Webservices, only SOAP based Webservices, and therefore do not need either servlet or class.
> Only 2 sub modules contain RESTful Webservices and have a class extending javax.ws.rs.core.Application.
> Following jaikiran's analysis, the existence of at least one JAX-RS subdeployment triggers the warning message for all other web modules in the war.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8586) Warning "WFLYRS0015: No Servlet declaration found for JAX-RS application." raised for non-JAX-RS submodules
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-8586?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated WFLY-8586:
----------------------------------
Fix Version/s: 11.0.0.Beta1
> Warning "WFLYRS0015: No Servlet declaration found for JAX-RS application." raised for non-JAX-RS submodules
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8586
> URL: https://issues.jboss.org/browse/WFLY-8586
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 11.0.0.Alpha1
> Reporter: Frank Langelage
> Assignee: Alessio Soldano
> Fix For: 11.0.0.Beta1
>
>
> When deploying my application (ear with a couple of jar and war files) on Wildfly 11.0.0.Beta1-SNAPSHOT I get warnings like this one for all the war files:
> {noformat}
> WARN [org.jboss.as.jaxrs#deploy] WFLYRS0015: No Servlet declaration found for JAX-RS application. In ws-common.war either provide a class that extends javax.ws.rs.core.Application or declare a servlet class in web.xml.
> {noformat}
> When deploying the same ear file on a Wildfly 10.1. this warning message does not appear.
> Those war files raising the warnings do not contain RESTful Webservices, only SOAP based Webservices, and therefore do not need either servlet or class.
> Only 2 sub modules contain RESTful Webservices and have a class extending javax.ws.rs.core.Application.
> Following jaikiran's analysis, the existence of at least one JAX-RS subdeployment triggers the warning message for all other web modules in the war.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months