[JBoss JIRA] (WFLY-3664) Exceptions during download of webstart libraries
by Christian Bourque (JIRA)
[ https://issues.jboss.org/browse/WFLY-3664?page=com.atlassian.jira.plugin.... ]
Christian Bourque commented on WFLY-3664:
-----------------------------------------
We have the same issue on 8.2.0.Final! Are there any plans to fix this?
> Exceptions during download of webstart libraries
> ------------------------------------------------
>
> Key: WFLY-3664
> URL: https://issues.jboss.org/browse/WFLY-3664
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 (64bit), Windows Server 2012 R2 (64bit)
> Reporter: Markus Schwarz
> Assignee: Stuart Douglas
> Priority: Minor
> Attachments: demo-src.zip, server.log
>
>
> I have a webstart application using the JnlpDownloadServlet. If the client cache is empty, launching the JNLP will download the libraries. The webstart application works as expected, but in the server logs there are many errors regarding download of the libraries.
> Just to mention: Not always the same libraries are listed with erros in the logs files. Sometimes I even got now exceptions.
> For my tests I used Wildfly 8.1.0.FINAL as well as a nightly build from 24. of July without any further changes of the configuration files (https://ci.jboss.org/hudson/job/WildFly-latest-master/).
> I tested it under Windows 7 and Windows Server 2012 R2. The demo contains an older JnlpDownloadServlet, but I tested it also with the one coming with JDK 7u65.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3578) jboss-cli.bat always exits with return code 0 even after a cli failure
by Brad Hawthorne (JIRA)
[ https://issues.jboss.org/browse/WFLY-3578?page=com.atlassian.jira.plugin.... ]
Brad Hawthorne commented on WFLY-3578:
--------------------------------------
This does not seem to be actually fixed in the 8.2.0.Final release. jboss-cli.bat still seems to always return 0, and if you examine the file this patch has not been applied.
> jboss-cli.bat always exits with return code 0 even after a cli failure
> ----------------------------------------------------------------------
>
> Key: WFLY-3578
> URL: https://issues.jboss.org/browse/WFLY-3578
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 8.1.0.Final
> Environment: Windows
> Reporter: Gabriele Garuglieri
> Assignee: Alexey Loubyansky
> Fix For: 8.2.0.Final
>
>
> jboss-cli.bat cannot be reliably controlled by other scripts because it does not report return code from cli execution and always exits with 0 even after a failure.
> It can be solved with the following patch:
> {noformat}
> --- C:/home/JBoss/wildfly-8.1.0.Final/bin/jboss-cli-orig.bat Sat May 31 04:54:25 2014
> +++ C:/home/JBoss/wildfly-8.1.0.Final/bin/jboss-cli.bat Thu Jul 03 10:19:09 2014
> @@ -1,4 +1,5 @@
> @echo off
> +setlocal ENABLEEXTENSIONS
> rem -------------------------------------------------------------------------
> rem JBoss Admin CLI Script for Windows
> rem -------------------------------------------------------------------------
> @@ -48,6 +49,7 @@
> if not exist "%JBOSS_RUNJAR%" (
> echo Could not locate "%JBOSS_RUNJAR%".
> echo Please check that you are in the bin directory when running this script.
> + set /A RC=1
> goto END
> )
>
> @@ -71,5 +73,11 @@
> org.jboss.as.cli ^
> %*
>
> +set /A RC=%errorlevel%
> :END
> if "x%NOPAUSE%" == "x" pause
> +
> +if "x%RC%" == "x" (
> + set /A RC=0
> +)
> +exit /B %RC%
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ELY-24) Add support to verify a password to LDAP realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-24?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-24:
--------------------------------
Fix Version/s: 1.0.0.Alpha1
(was: 1.0.0.Beta1)
> Add support to verify a password to LDAP realm
> ----------------------------------------------
>
> Key: ELY-24
> URL: https://issues.jboss.org/browse/ELY-24
> Project: WildFly Elytron
> Issue Type: Sub-task
> Components: Realms
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha1
>
>
> This is to add support to take a clear text password and use it to connect to LDAP to verify the users identity.
> _Note: This is provided for legacy purposes rather than as a preferred solution. Ideally either one of the solutions which retrieves the password from LDAP would be used or GSSAPI depending on the overall architecture._
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3873) AJP-connector mangles SOAP-request
by xiaodong xie (JIRA)
[ https://issues.jboss.org/browse/WFLY-3873?page=com.atlassian.jira.plugin.... ]
xiaodong xie commented on WFLY-3873:
------------------------------------
"jsonData":"\u00124\u001F�\u001F�{\"startx\":\"34
4\", ......
The JSON received by the handling code starts with weird unicode stuff. It was not for every request, just happened for part of the requests.
Thanks.
> AJP-connector mangles SOAP-request
> ----------------------------------
>
> Key: WFLY-3873
> URL: https://issues.jboss.org/browse/WFLY-3873
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Linux
> reverse-proxy from Apache 2.2 via mod_proxy_ajp to AJP connector on WildFly 8.1.0-Final
> Reporter: Gerke Ephorus
> Assignee: Stuart Douglas
> Labels: .net, ajp, soap
>
> When connecting to WildFly 8.1.0-Final SOAP-service from a .NET application via a reverse-proxy (Apache 2.2 with mod_proxy_ajp to the AJP-connector) it looks like the payload SOAP package gets mangled:
> {noformat}
> 2014-09-19 08:45:05,206 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-99) Interceptor for {http://ephorus.com/document-processor/ws/}DocumentProcessor has thrown exception, unwinding now: java.lang.RuntimeException:
> Couldn't parse stream.
> at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1447)
> at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:123)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:93)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:133)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.2.2.Final.jar:2.2.2.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:101) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1)
> at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:536)
> at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:585)
> at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:610)
> at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:316)
> at __redirected.__XMLInputFactory.createXMLStreamReader(__XMLInputFactory.java:142) [jboss-modules.jar:1.3.3.Final]
> at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1445)
> ... 40 more
> Caused by: java.io.CharConversionException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1)
> at com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:303)
> at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:189)
> at com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
> at com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
> at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:531)
> ... 45 more
> {noformat}
> Connecting to the same SOAP-service via the reverse-proxy via the AJP from a different party/client does not show this problem.
> Connecting to the same SOAP-service directly to the http-connector on the same WildFly 8.1.0-Final server does not show this problem.
> Wild guess is that it depends somehow on the HTTP-headers of the .NET client. These are the headers captured via Fiddler-http-proxy on the client-side:
> {noformat}
> POST http://some.host.com/doce/Foo/Bar HTTP/1.1
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3082)
> Content-Type: text/xml; charset=utf-8
> SOAPAction: "http://host/some/soap-action/ws/addDocument"
> Host: some.host.com
> Content-Length: 6592
> Expect: 100-continue
> Connection: Keep-Alive
> Accept: application/json, text/plain, */*
> {noformat}
> There is a small change it's the same root-cause as [WFLY-2999]. Maybe I'll find the time to test this on 9.0.0-Beta1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3873) AJP-connector mangles SOAP-request
by xiaodong xie (JIRA)
[ https://issues.jboss.org/browse/WFLY-3873?page=com.atlassian.jira.plugin.... ]
xiaodong xie commented on WFLY-3873:
------------------------------------
Well, we are still experiencing this issue, but with JSON format. It's a Rails application uses REST style endpoints exposed by Wildfly 8.2. Rails talks to Apache (mod_jk), and Apache talks to Wildfly 8.2 (ajp-listener)
Caused by: ! org.jboss.resteasy.spi.ReaderException: java.lang.NullPointerException
! at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:183)
! at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:89)
! at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:112)
! at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
! at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
! at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
! at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
!... 39 common frames omitted
Caused by: ! java.lang.NullPointerException: null
! at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:171)
! at io.undertow.servlet.spec.ServletInputStreamImpl.read(ServletInputStreamImpl.java:146)
! at io.undertow.servlet.spec.ServletInputStreamImpl.read(ServletInputStreamImpl.java:133)
! at io.undertow.servlet.spec.ServletInputStreamImpl.read(ServletInputStreamImpl.java:124)
! at java.io.InputStream.read(InputStream.java:170)
! at org.jboss.resteasy.plugins.providers.ProviderHelper.readString(ProviderHelper.java:66)
! at org.jboss.resteasy.plugins.providers.StringTextStar.readFrom(StringTextStar.java:40)
! at org.jboss.resteasy.plugins.providers.StringTextStar.readFrom(StringTextStar.java:22)
! at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom(AbstractReaderInterceptorContext.java:59)
! at org.jboss.resteasy.core.interception.ServerReaderInterceptorContext.readFrom(ServerReaderInterceptorContext.java:62)
! at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:51)
! at org.jboss.resteasy.security.doseta.DigitalVerificationInterceptor.aroundReadFrom(DigitalVerificationInterceptor.java:32)
! at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:53)
! at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.aroundReadFrom(GZIPDecodingInterceptor.java:59)
! at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:53)
! at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:150)
!... 45 common frames omitted
Thanks a lot for the help in advance.
> AJP-connector mangles SOAP-request
> ----------------------------------
>
> Key: WFLY-3873
> URL: https://issues.jboss.org/browse/WFLY-3873
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Linux
> reverse-proxy from Apache 2.2 via mod_proxy_ajp to AJP connector on WildFly 8.1.0-Final
> Reporter: Gerke Ephorus
> Assignee: Stuart Douglas
> Labels: .net, ajp, soap
>
> When connecting to WildFly 8.1.0-Final SOAP-service from a .NET application via a reverse-proxy (Apache 2.2 with mod_proxy_ajp to the AJP-connector) it looks like the payload SOAP package gets mangled:
> {noformat}
> 2014-09-19 08:45:05,206 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-99) Interceptor for {http://ephorus.com/document-processor/ws/}DocumentProcessor has thrown exception, unwinding now: java.lang.RuntimeException:
> Couldn't parse stream.
> at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1447)
> at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:123)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:93)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:133)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.2.2.Final.jar:2.2.2.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:101) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1)
> at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:536)
> at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:585)
> at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:610)
> at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:316)
> at __redirected.__XMLInputFactory.createXMLStreamReader(__XMLInputFactory.java:142) [jboss-modules.jar:1.3.3.Final]
> at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1445)
> ... 40 more
> Caused by: java.io.CharConversionException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1)
> at com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:303)
> at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:189)
> at com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
> at com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
> at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:531)
> ... 45 more
> {noformat}
> Connecting to the same SOAP-service via the reverse-proxy via the AJP from a different party/client does not show this problem.
> Connecting to the same SOAP-service directly to the http-connector on the same WildFly 8.1.0-Final server does not show this problem.
> Wild guess is that it depends somehow on the HTTP-headers of the .NET client. These are the headers captured via Fiddler-http-proxy on the client-side:
> {noformat}
> POST http://some.host.com/doce/Foo/Bar HTTP/1.1
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3082)
> Content-Type: text/xml; charset=utf-8
> SOAPAction: "http://host/some/soap-action/ws/addDocument"
> Host: some.host.com
> Content-Length: 6592
> Expect: 100-continue
> Connection: Keep-Alive
> Accept: application/json, text/plain, */*
> {noformat}
> There is a small change it's the same root-cause as [WFLY-2999]. Maybe I'll find the time to test this on 9.0.0-Beta1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-508) Remove need to maintain discovery-option ordering separately from the option
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-508:
---------------------------------------
Summary: Remove need to maintain discovery-option ordering separately from the option
Key: WFCORE-508
URL: https://issues.jboss.org/browse/WFCORE-508
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Alexey Loubyansky
Fix For: 1.0.0.Beta1
The various discovery-option (including the static-discovery variant) are represented as resources, with the ordering between them maintained in the parent /host=*/core-service=discovery-options resources.
This is too troublesome for the non-xml filesystem-based persistence stuff Alexey Loubyansky is working on, and is non-standard in general, as we are striving toward using lists instead of child resources.
I propose the following:
1) The /host=*/core-service=discovery-options "discovery-options" attribute should be converted into LIST of OBJECT from the current LIST of STRING.
If we can come up with a good name for an attribute, we can just add a new one and deprecate the old one, preserving compatibility. But if we do that the old "discovery-options" attribute can't be writable any longer.
2) The elements in the list can be of varied types. This reflects the fact that there are varied types of child resources (discovery-option and static-discovery). In the metadata this will be handled as if a general "discovery-option" type were a complex object with alternative top level fields. For example in the r-r-d output
{code}
"discovery-options" => {
"type" => LIST,
"value-type" => {
"static-discovery" => {
"alternatives" => ["custom-discovery"],
"type" => OBJECT,
"value-type" => {
"protocol" => {...},
"host" => {...}
"port" => {...}
}
},
"custom-discovery" => {
"alternatives" => ["static-discovery"]
"type" => OBJECT,
"value-type" => {
"code" => {...},
"module" => {...},
"properties" => {...}
}
}
}
}
{code}
3) We should continue to support the existing child resources as a sort of runtime-only (i.e. not directly persisted) alias into an item in the list. The Resource implementation for /host=*/core-service=discovery-options dynamically generates these. The persistence logic completely ignores them.
The problem is the child resource needs a name, while the list elements above really don't. We could require a superfluous "alias" attribute in the list elements, and probably we could generate one if one isn't provided. If an alias isn't provided, the name of the child resource becomes "unaliased-X" where X is the current index in the list. For a given element this could change though if the list changes. If people want a consistent name, provide an alias.
With these non-persistent child resources, we can still support the "add" operation. Invoking it has the result of adding a new element to the list.
The child resources could include an attribute indicating their current list position. This would be read-only (i.e. no trying to reorder the list by changing this) but perhaps the "add" op could accept it as a param to indicate the initial position in the list.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-690) Deadlock on LeftTupleSets
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-690:
----------------------------------
Summary: Deadlock on LeftTupleSets
Key: DROOLS-690
URL: https://issues.jboss.org/browse/DROOLS-690
Project: Drools
Issue Type: Bug
Reporter: Mario Fusco
Assignee: Mario Fusco
The following deadlock has been reported:
{code}
Java stack information for the threads listed above:
===================================================
"drools-worker-2":
at org.drools.core.common.DefaultAgenda.addEagerRuleAgendaItem(DefaultAgenda.java:282)
- waiting to lock <0x00000007d8fc80d0> (a java.util.LinkedList)
at org.drools.core.reteoo.PathMemory.queueRuleAgendaItem(PathMemory.java:153)
at org.drools.core.reteoo.PathMemory.doLinkRule(PathMemory.java:120)
- locked <0x00000007d91f34d0> (a org.drools.core.reteoo.PathMemory)
at org.drools.core.reteoo.PathMemory.linkSegment(PathMemory.java:90)
at org.drools.core.reteoo.SegmentMemory.notifyRuleLinkSegment(SegmentMemory.java:170)
at org.drools.core.reteoo.LeftInputAdapterNode$LiaNodeMemory.setNodeDirty(LeftInputAdapterNode.java:645)
at org.drools.core.reteoo.LeftInputAdapterNode.doUpdateSegmentMemory(LeftInputAdapterNode.java:396)
- locked <0x00000007d91f68a8> (a java.lang.Object)
at org.drools.core.reteoo.LeftInputAdapterNode.doUpdateObject(LeftInputAdapterNode.java:366)
at org.drools.core.reteoo.LeftInputAdapterNode.modifyObject(LeftInputAdapterNode.java:436)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:512)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:437)
at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:382)
at org.drools.core.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:273)
at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:511)
at org.drools.core.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:385)
at drools.core.Rule_vme$u46$phases_inconnues1199361134.defaultConsequence(Rule_vme$u46$phases_inconnues1199361134.java:19)
at drools.core.Rule_vme$u46$phases_inconnues1199361134DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
at drools.core.Rule_vme$u46$phases_inconnues1199361134DefaultConsequenceInvoker.evaluate(Unknown Source)
at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1046)
- locked <0x00000007d8fc8080> (a org.drools.core.common.DefaultAgenda)
at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:152)
at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:100)
- locked <0x00000007d9335498> (a org.drools.core.phreak.RuleExecutor)
at org.drools.core.phreak.PhreakTimerNode$Executor.evauateAndFireRule(PhreakTimerNode.java:483)
at org.drools.core.phreak.PhreakTimerNode$TimerNodeJob$1.run(PhreakTimerNode.java:420)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
"Drools thread":
at org.drools.core.common.SynchronizedLeftTupleSets.takeAll(SynchronizedLeftTupleSets.java:44)
- waiting to lock <0x00000007d91f68a8> (a java.lang.Object)
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:112)
at org.drools.core.phreak.RuleExecutor.evaluateNetwork(RuleExecutor.java:77)
- locked <0x00000007d9334c40> (a org.drools.core.phreak.RuleExecutor)
at org.drools.core.common.DefaultAgenda.evaluateEagerList(DefaultAgenda.java:990)
- locked <0x00000007d8fc80d0> (a java.util.LinkedList)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:945)
at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1190)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1329)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1306)
at drools.core.Core$2.run(Core.java:495)
at java.lang.Thread.run(Thread.java:744)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months