[JBoss JIRA] (WFLY-9724) [GSS](7.1.z) Undertow does not allow UTF-8 characters in URLs
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9724?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-14128 to WFLY-9724:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9724 (was: JBEAP-14128)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: (was: 7.1.0.CR3)
Fix Version/s: (was: 7.1.1.GA)
> [GSS](7.1.z) Undertow does not allow UTF-8 characters in URLs
> -------------------------------------------------------------
>
> Key: WFLY-9724
> URL: https://issues.jboss.org/browse/WFLY-9724
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Labels: downstream_dependency, qe-pre-ack
>
> We receive a 400 response code if using UTF-8 characters for a request, due to this check:
> https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
> This was introduced in UNDERTOW-1101. We want to understand why it is necessary for the CVE/CWE regarding request smuggling, but this ticket is to at least make this check optional as it goes against the URL_ENCODING UndertowOption when set to UTF-8 (default).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3539) Flunky controller tests on Windows: Address already in use
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3539:
------------------------------------------
The crappy workaround is merged, but I'll be happy to see it reverted if there's a better way.
> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
> Key: WFCORE-3539
> URL: https://issues.jboss.org/browse/WFCORE-3539
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 4.0.0.Alpha6
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes...
> But it is sufficient to run combination of tests above on Windows to reproduce.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9720) org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes high amount of CPU
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9720?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-9720:
--------------------------------------
Assignee: Osamu Nagano (was: Scott Marlow)
Resolution: Done
> org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes high amount of CPU
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-9720
> URL: https://issues.jboss.org/browse/WFLY-9720
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Osamu Nagano
> Assignee: Osamu Nagano
> Labels: regression
> Fix For: 12.0.0.Alpha1
>
>
> JIPI-32 is fixed in the following classes:
> {code}
> jpa/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
> jpa/hibernate4_3/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
> {code}
> But not in the following class:
> {code}
> jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/management/QueryName.java
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9723) Multiple discovery protocols - add MULTI_PING automatically
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-9723:
------------------------------------
Summary: Multiple discovery protocols - add MULTI_PING automatically
Key: WFLY-9723
URL: https://issues.jboss.org/browse/WFLY-9723
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Affects Versions: 11.0.0.Final
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Previously, only one discovery protocol could have been used per stack. To allow for multiple discovery protocols in JGroups, MULTI_PING (JGRP-2224) protocol was implemented which did not require all protocols to be modified to support the change (especially since many protocols now reside outside the main jgroups project).
Though, this is a temporary measure which is planned to be remedied in JGroups 5.x with JGRP-2230 where MULTI_PING will no longer be required.
To remedy the inconvenience, we could add MULTI_PING automatically for JGroups 4.x release (in somewhat similar fashion FORK is added).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2230) Multiple discovery protocols without MULTI_PING
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2230?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on JGRP-2230:
--------------------------------------
It should be possible to introduce a new API already in 4.x that protocols themselves can already (i.e. optionally) implement so they can be ready for 5.x when the time comes without code changes.
> Multiple discovery protocols without MULTI_PING
> -----------------------------------------------
>
> Key: JGRP-2230
> URL: https://issues.jboss.org/browse/JGRP-2230
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> Currently, {{MULTI_PING}} is needed to forward discovery requests to multiple discovery protocols. If we change the API in 5.0, and pass a {{Responses}} object down to the discovery protocols, and each discovery protocol forwards discovery requests down (and responses up), and they all add responses to the same {{Responses}} object, then we would not need {{MULTI_PING}} any longer.
> However, this is an API change, so can be done only in 5.0.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ]
David Lloyd commented on LOGTOOL-132:
-------------------------------------
Ah, well the bulk of the metaspace reduction should come from the fact that most of the internal structures that are consuming substantial metaspace can be deleted if the methods are final based on an analysis that Andrew Dinn has done.
Also, moving the strings out of the class moves that memory overhead to the heap out of metaspace, but the point of doing this is really because it's the only practical way I know of to allow the class to be final.
> Support low-metaspace bundles/classes
> -------------------------------------
>
> Key: LOGTOOL-132
> URL: https://issues.jboss.org/browse/LOGTOOL-132
> Project: Log Tool
> Issue Type: Enhancement
> Reporter: David Lloyd
> Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGTOOL-132:
---------------------------------------
For loggers there is potential for it to happen many times. A mapping of log messages can't be static on a logger as there is a {{Logger.getMessageLogger(Class<T>, String, Locale)}} option so if the user doesn't use a static logger each instantiation will read a properties file.
I guess the real question is going to be is the metaspace size of having a mapping of messages vs having each string having a method going to significantly decrease the size. My gut is for English only maybe not that much. For other languages it may be a lot more significant.
Anyway, I'll give it a test. Removing the static strings and adding a method in jboss-logging to remove the stack trace entry for exceptions only saves about 6% on English interfaces.
> Support low-metaspace bundles/classes
> -------------------------------------
>
> Key: LOGTOOL-132
> URL: https://issues.jboss.org/browse/LOGTOOL-132
> Project: Log Tool
> Issue Type: Enhancement
> Reporter: David Lloyd
> Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3539) Flunky controller tests on Windows: Address already in use
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-3539 at 1/23/18 3:34 PM:
-------------------------------------------------------------------
[~honza889] Sure, that would be better, particularly if it is easy to set up and avoids conflicts with random other stuff that may be on the machine. Note that it's different ports per test method not just per test class. The failures are usually within the same class.
Also, I thought about looping through a set of expected-to-be ok ports (rather than just blindly incrementing and hoping you don't hit a conflict) but a caveat is I've observed that just a 50 ms sleep still produced failures. 100 ms seemed ok, at least on ci.wildfly.org. So any set of "ok ports" would have to be big enough to allow enough tests to run and time to pass before starting over.
was (Author: brian.stansberry):
[~honza889] Sure, that would be better, particularly if it is easy to set up and avoids conflicts with random other stuff that may be on the machine. Note that it's different ports per test method not per test class. The failures are usually within the same class.
> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
> Key: WFCORE-3539
> URL: https://issues.jboss.org/browse/WFCORE-3539
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 4.0.0.Alpha6
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes...
> But it is sufficient to run combination of tests above on Windows to reproduce.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ]
David Lloyd commented on LOGTOOL-132:
-------------------------------------
Any I/O that happens only one time on construction should acceptable because it is only done once, and it is loading from the JAR as the class itself.
> Support low-metaspace bundles/classes
> -------------------------------------
>
> Key: LOGTOOL-132
> URL: https://issues.jboss.org/browse/LOGTOOL-132
> Project: Log Tool
> Issue Type: Enhancement
> Reporter: David Lloyd
> Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3539) Flunky controller tests on Windows: Address already in use
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3539:
------------------------------------------
[~honza889] Sure, that would be better, particularly if it is easy to set up and avoids conflicts with random other stuff that may be on the machine. Note that it's different ports per test method not per test class. The failures are usually within the same class.
> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
> Key: WFCORE-3539
> URL: https://issues.jboss.org/browse/WFCORE-3539
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 4.0.0.Alpha6
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes...
> But it is sufficient to run combination of tests above on Windows to reproduce.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months