[JBoss JIRA] (WFCORE-1585) Logging handler lost due to conflict handlers in logging.properties and standalone.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1585?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated WFCORE-1585:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1345816
Bugzilla Update: Perform
> Logging handler lost due to conflict handlers in logging.properties and standalone.xml
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1585
> URL: https://issues.jboss.org/browse/WFCORE-1585
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 2.0.10.Final
> Reporter: Takayoshi Kimura
> Assignee: James Perkins
> Attachments: logging.properties
>
>
> Console logging doesn't work after logging subsystem init with the following configuration.
> * logging.properties is configured with ASYNC with CONSOLE handlers.
> * standalone.xml is configured with stock FILE and CONSOLE handlers.
> Background of why there is a mismatch between logging.properties and standalone.xml, EAP image for OpenShift is configured with ASYNC with CONSOLE handlers by default. But users can customize standalone.xml and apply custom configuration based on the stock standalone.xml.
> Expected result is logging configuration from standalone.xml is applied once logging subsystem come up regardless the mismatch.
> Most likely related to WFCORE-159.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6678) StackoverflowError ejbclientinvocationcontext
by Jimmy Pannier (JIRA)
[ https://issues.jboss.org/browse/WFLY-6678?page=com.atlassian.jira.plugin.... ]
Jimmy Pannier commented on WFLY-6678:
-------------------------------------
Hi jaikiran pai, the code is in textbox of "steps to reproduce" (above )
> StackoverflowError ejbclientinvocationcontext
> ---------------------------------------------
>
> Key: WFLY-6678
> URL: https://issues.jboss.org/browse/WFLY-6678
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: wildfly 9.0.1, jdk 1.8
> Reporter: Jimmy Pannier
> Attachments: server.log
>
>
> Sometimes after few days i get an exception
> Here is a stacktrace.
> 2016-06-07 07:38:10,441 ERROR [org.jboss.as.ejb3.invocation] (default task-76) WFLYEJB0034: EJB Invocation failed on component StorageServiceImpl for method public abstract java.util.List com.inovelan.cloud.api.storage.service.dataset.IStorageEjbService.loadData(com.inovelan.cloud.api.storage.model.dto.dataset.LoadDataConfig): javax.ejb.EJBTransactionRolledbackException: WFLYEJB0457: Unexpected Error
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:153)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> .....
> Caused by: java.lang.StackOverflowError
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1578) Better check of names of existing resources when adding '{local|remote-destination-outbound-socket-binding'
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1578?page=com.atlassian.jira.plugi... ]
Carlo de Wolf updated WFCORE-1578:
----------------------------------
Labels: downstream_dependency (was: )
> Better check of names of existing resources when adding '{local|remote-destination-outbound-socket-binding'
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1578
> URL: https://issues.jboss.org/browse/WFCORE-1578
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
> Labels: downstream_dependency
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> Lets have some {{/socket-binding-group=standard-sockets/socket-binding}} with particular name. Then when I create some {{/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding}} or {{/socket-binding-group=standard-sockets/local-destination-outbound-socket-binding}} using same name as of already existing {{socket-binding}} resource, {{add}} operation is successful but when I perform server reload, it crashes as it is not able to parse configuration. See:
> # Start EAP and log to CLI
> # create your own {{socket-binding}} resource and {{\{remote|local\}-destination-outbound-socket-binding}} resource with same names and perform reload
> {code}
> /socket-binding-group=standard-sockets/socket-binding=myBinding:add()
> /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=myBinding:add(host=localhost,port=8765)
> or
> /socket-binding-group=standard-sockets/local-destination-outbound-socket-binding=myBinding:add(socket-binding-ref=http)
> reload
> {code}
> # server crashes with following stacktrace in console log:
> {code}
> 17:31:40,447 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 17:31:40,453 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0008: Undertow HTTP listener default suspending
> 17:31:40,454 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 17:31:40,454 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping
> 17:31:40,458 INFO [org.jboss.as.mail.extension] (MSC service thread 1-7) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default]
> 17:31:40,461 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 22ms
> 17:31:40,461 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) starting
> 17:31:40,489 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.server.ServerService.boot(ServerService.java:356)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[410,9]
> Message: WFLYCTL0042: A socket-binding or a outbound-socket-binding myBinding already declared has already been declared in socket-binding-group standard-sockets
> at org.jboss.as.server.parsing.StandaloneXml_4.parseSocketBindingGroup(StandaloneXml_4.java:518)
> at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:254)
> at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:141)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:103)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> 17:31:40,490 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 17:31:40,491 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 17:31:40,496 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 3ms
> {code}
> After this occurs, one needs to fix {{./standalone/configuration/standalone.xml}} manually by removing duplicate resources.
> If there is a problem for those resources to have same names I would welcome that names are checked during the {{add}} operation already regarding to all resources in {{socket-binding}} and {{\{remote|local\}-destination-outbound-socket-binding}}.
> Note: not sure whether CLI component is appropriate, please change if there is better component for this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6671) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6671?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6671:
--------------------------------------
I just tested this out locally against Apache 2.4.16 with mod proxy AJP and it appears to work fine. Is this specific to mod_jk or does mod_proxy_ajp fail for you as well ?
> ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6671
> URL: https://issues.jboss.org/browse/WFLY-6671
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: Apache HTTP server 2.2.22 with mod_jk
> Reporter: river shen
> Assignee: Stuart Douglas
> Attachments: service-1.0-SNAPSHOT.war, src.zip, stacks.txt, standalone.xml, workers.properties
>
>
> When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
> if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.
> It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.
> We have attached a minimal web application that reproduce this issue.
> Also attached is the standalone.xml and the apache configuration file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6684) JMS Bridge should display statistics about messages that have been processed.
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-6684?page=com.atlassian.jira.plugin.... ]
Chen Maoqian commented on WFLY-6684:
------------------------------------
i have commited a pr of artemis project,so if we want to apply this feature,we must upgrade the messaging.i will fix the wildfly to apply this feature and write a test case to validate this feature.
> JMS Bridge should display statistics about messages that have been processed.
> -----------------------------------------------------------------------------
>
> Key: WFLY-6684
> URL: https://issues.jboss.org/browse/WFLY-6684
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Environment: JBoss EAP 7
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
>
> The JMS bridge should show some statistics about messages that have been processed through the bridge for example:
> - number of messages successfully committed
> - number of messages aborted/rollback
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6153) [Migration][WebToUndertow] RemoteIpValve is not correctly migrated
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6153?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-6153:
--------------------------------------
The PR was merged, so it looks like this can be resolved [~ehugonnet]?
> [Migration][WebToUndertow] RemoteIpValve is not correctly migrated
> ------------------------------------------------------------------
>
> Key: WFLY-6153
> URL: https://issues.jboss.org/browse/WFLY-6153
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
>
> When migrating RemoteIpValve which looks like this
> {code:xml}
> <valve name="remote-ip-valve" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteIpValve">
> <param param-name="httpServerPort" param-value="8080"/>
> <param param-name="httpsServerPort" param-value="8443"/>
> <param param-name="internalProxies" param-value="192.*|127.*"/>
> <param param-name="trustedProxies" param-value="10.*"/>
> <param param-name="protocolHeaderHttpsValue" param-value="https"/>
> <param param-name="protocolHeader" param-value="X-Forwarded-Proto"/>
> <param param-name="remoteIpHeader" param-value="X-Forwarded-For"/>
> <param param-name="proxiesHeader" param-value="X-Forwarded-By"/>
> </valve>
> {code}
> it is migrated to expression filter looking like this
> {noformat}
> <expression-filter expression="regexp(pattern="10.*", value=%{i, x-forwarded-for}, full-match=true) and regexp(pattern="192.*|127.*", value=%{i, x-forwarded-for}, full-match=true) -> { proxy-peer-address(); }" name="remote-ip-valve"/>
> {noformat}
> When doing request to http://127.0.0.1:8080/ it fails with 500 and this exception in log
> {noformat}
> 14:06:53,648 ERROR [io.undertow.request] (default I/O-4) UT005071: Undertow request failed HttpServerExchange{ GET / request {Accept=[*/*], User-Agent=[curl/7.43.0-DEV], Host=[127.0.0.1:8080]} response {}}: java.lang.IllegalArgumentException: UT000045: Error parsing predicated handler string Expecting , or ):
> regexp(pattern="10.*", value=%{i, x-forwarded-for}, full-match=true) and regexp(pattern="192.*|127.*", value=%{i, x-forwarded-for}, full-match=true) -> { proxy-peer-address(); }
> ^
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.error(PredicatedHandlersParser.java:727)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parseExpression(PredicatedHandlersParser.java:506)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:381)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:322)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:85)
> at org.wildfly.extension.undertow.filters.ExpressionFilterDefinition.createHttpHandler(ExpressionFilterDefinition.java:88)
> at org.wildfly.extension.undertow.filters.FilterService.createHttpHandler(FilterService.java:57)
> at org.wildfly.extension.undertow.filters.FilterRef.createHttpHandler(FilterRef.java:69)
> at org.wildfly.extension.undertow.LocationService.configureHandlerChain(LocationService.java:96)
> at org.wildfly.extension.undertow.Host.configureRootHandler(Host.java:117)
> at org.wildfly.extension.undertow.Host.getOrCreateRootHandler(Host.java:171)
> at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:285)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:64)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:233)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:131)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:145)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:121)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
> {noformat}
> The exception is caused by not having in quotes the '%\{i, x-forwarded-for\}'.
> Also there is no predicate named {{regexp}}, the correct name is {{regex}}.
> As this is hidden to the customer during the migration operation and is not visible before customer sends request to the server marking as blocker.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6154) [Migration][WebToUndertow] RemoteAddrValve and RemoteHostValve are incorrectly migrated
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6154?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-6154:
--------------------------------------
The PR was merged, so it looks like this can be resolved [~ehugonnet]?
> [Migration][WebToUndertow] RemoteAddrValve and RemoteHostValve are incorrectly migrated
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-6154
> URL: https://issues.jboss.org/browse/WFLY-6154
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
>
> When migrating {{RemoteHostValve}} or {{RemoteAddrValve}} which contains multiple allows or denies or contains both as in \[1\], it is migrated incorrectly. In the resulting expression the acl attribute should be in format {{acl=\{'xxx allow', 'yyy deny'\}}}, but instead it results in {{acl='xxx allow, yyy deny'}} which is incorrect and results in exception when doing any request to the server.
> Marking as critical as that it was migrated incorrectly the customer will not find out during migration but when actually doing request to the server.
> Might be interesting to [~ehugonnet]
> [1]
> {code:xml}
> <valve name="request-filter" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve">
> <param param-name="deny" param-value="10.0.0.1"/>
> <param param-name="allow" param-value="127.*"/>
> </valve>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months