[JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1893:
--------------------------------
Apparently, the JDK on Windows doesn't implement {{DatagramSocketImpl.setTimeToLive()}}. Can you try a different JDK (e.g. JDK 8), to see if it implements this method ?
If not, Windows users will have to live with this until JGroups 4.0 (which switches to NIO.2). You can make the error message go away though by removing {{ip_ttl}} from the config.
> ENCRYPT: Thread safety issues during key changes
> ------------------------------------------------
>
> Key: JGRP-1893
> URL: https://issues.jboss.org/browse/JGRP-1893
> Project: JGroups
> Issue Type: Bug
> Reporter: Tero Leppikangas
> Assignee: Bela Ban
>
> For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized.
> I have implemented one solution by wrapping the state in separate object which can be found here:
> https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety
> I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest
by Marcial Atiénzar Navarro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.... ]
Marcial Atiénzar Navarro commented on WFLY-4037:
------------------------------------------------
If I activate sso betweens apps,it's cluster activated by default?
> Error 500 accessing png,css, rest
> ---------------------------------
>
> Key: WFLY-4037
> URL: https://issues.jboss.org/browse/WFLY-4037
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Marcial Atiénzar Navarro
> Assignee: Paul Ferraro
> Priority: Critical
>
> I've this error:
> {code}
> 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.get(CacheImpl.java:377)
> at org.infinispan.CacheImpl.get(CacheImpl.java:369)
> at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
> at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38)
> at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50)
> at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [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.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [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.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [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.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_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (WFCORE-201) UnboundedQueueThreadPool's keep-alive param is currently useless
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/WFCORE-201?page=com.atlassian.jira.plugin... ]
James Livingston commented on WFCORE-201:
-----------------------------------------
Any preference for adding a core-threads parameter (so schema change etc), or just setting the executor's core-threads to 0?
> UnboundedQueueThreadPool's keep-alive param is currently useless
> ----------------------------------------------------------------
>
> Key: WFCORE-201
> URL: https://issues.jboss.org/browse/WFCORE-201
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 1.0.0.Alpha10
> Reporter: James Livingston
>
> UnboundedQueueThreadPoolService currently sets the number of core thread and the maximum threads to the same value. As core threads are never removed, the keep-alive time parameter is useless.
> Either the core threads should be lowered (to 0?) to allow timeouts, or the keep-alive parameter removed/deprecated.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (DROOLS-638) KnowledgeAgent incremental build stuck infinite if have two rules with same condition in steam mode
by Hariprasad Taduru (JIRA)
[ https://issues.jboss.org/browse/DROOLS-638?page=com.atlassian.jira.plugin... ]
Hariprasad Taduru commented on DROOLS-638:
------------------------------------------
We are facing the above issue and not able to get a work around as well. Seems like a bug in the engine.
Could you please clarify on this?
> KnowledgeAgent incremental build stuck infinite if have two rules with same condition in steam mode
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-638
> URL: https://issues.jboss.org/browse/DROOLS-638
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final
> Environment: Windows 8 64bit Machine, Java jdk1.7.0_51
> Reporter: Vinay Pareek
> Assignee: Mark Proctor
> Attachments: AgentTest.zip
>
>
> If we have two rules on same condition in Steam mode, first time agent able to pick both and work fine.
> When we update any rule (then part), KnowledgeAgent will stuck infinite after printing below logs.
> [2014-10-24 17:59:04,066:debug] KnowledgeAgent received ChangeSet changed notification
> [2014-10-24 17:59:04,066:info] KnowledgeAgent applying ChangeSet
> [2014-10-24 17:59:04,067:debug] KnowledgeAgent removing mappings for resource=[FileResource file='rule\streamRule.drl'] with unsubscribe=false
> [2014-10-24 17:59:04,067:debug] KnowledgeAgent rebuilding KnowledgeBase using ChangeSet
> [2014-10-24 17:59:04,076:info] KnowledgeAgent performing an incremental build of the ChangeSet
> [2014-10-24 17:59:04,193:debug] KnowledgeAgent: Diffing: [FileResource file='rule\streamRule.drl']
> Below is code snippet for KnowledgeAgent
> KnowledgeAgentConfiguration kaconf = KnowledgeAgentFactory
> .newKnowledgeAgentConfiguration();
> kaconf.setProperty("drools.agent.scanDirectories", "true");
> kaconf.setProperty("drools.agent.newInstance", "false");
> KnowledgeBaseConfiguration config = KnowledgeBaseFactory
> .newKnowledgeBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> final KnowledgeAgent kagent = KnowledgeAgentFactory.newKnowledgeAgent(
> "kagent", kbase, kaconf);
> kagent.setSystemEventListener(new PrintStreamSystemEventListener());
> kagent.addEventListener(new KnowledgeAgentEventListener() {
> public void resourceCompilationFailed(
> ResourceCompilationFailedEvent arg0) {
> LOGGER.error("Unable to compile Knowledge" + arg0.toString());
> throw new RuntimeException("Unable to compile Knowledge"
> + arg0.toString());
> }
> public void knowledgeBaseUpdated(KnowledgeBaseUpdatedEvent arg0) {
> LOGGER.info("********** KBase was updated***********");
> }
> public void beforeResourceProcessed(
> BeforeResourceProcessedEvent arg0) {
> }
> public void beforeChangeSetProcessed(
> BeforeChangeSetProcessedEvent arg0) {
> }
> public void beforeChangeSetApplied(BeforeChangeSetAppliedEvent arg0) {
> }
> public void afterResourceProcessed(AfterResourceProcessedEvent arg0) {
> }
> public void afterChangeSetProcessed(
> AfterChangeSetProcessedEvent arg0) {
> }
> public void afterChangeSetApplied(AfterChangeSetAppliedEvent arg0) {
> }
> });
> ResourceChangeScannerConfiguration sconf = ResourceFactory
> .getResourceChangeScannerService()
> .newResourceChangeScannerConfiguration();
> sconf.setProperty("drools.resource.scanner.interval", "2");
> ResourceFactory.getResourceChangeScannerService().configure(sconf);
> kagent.applyChangeSet(ResourceFactory
> .newClassPathResource("changeset/changeSet.xml"));
> ResourceFactory.getResourceChangeNotifierService().start();
> ResourceFactory.getResourceChangeScannerService().start();
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment
by James Livingston (JIRA)
James Livingston created WFCORE-210:
---------------------------------------
Summary: IO error during deployment scanning triggers undeployment
Key: WFCORE-210
URL: https://issues.jboss.org/browse/WFCORE-210
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 1.0.0.Alpha10
Reporter: James Livingston
Assignee: Jason Greene
If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications.
This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs.
It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (WFLY-3754) EJB StatefulSessionComponentInstance methodMap includes final Object methods
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3754?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3754:
-----------------------------------------------
James Livingston <jlivings(a)redhat.com> changed the Status of [bug 1132270|https://bugzilla.redhat.com/show_bug.cgi?id=1132270] from NEW to CLOSED
> EJB StatefulSessionComponentInstance methodMap includes final Object methods
> ----------------------------------------------------------------------------
>
> Key: WFLY-3754
> URL: https://issues.jboss.org/browse/WFLY-3754
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 8.1.0.Final
> Reporter: James Livingston
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> StatefulSessionComponentInstance has a methodMap which maintains the ChainedInterceptors for each method. That currently includes final Object methods which are not Business Methods for EJBs (EJB 3.1 4.9.5 "The method must not be declared as final or static"), which results in extra memory overhead for what I believe is the useless interceptors.
> The amount of memory a ChainedInterceptor consumes varies between JVMs, but it is between 280 and 400 bytes in some heap dumps I looked at. With 6 final methods (wait, notify*, getClass) on java.lang.Object that adds approximately 2kb of memory use to each instance of each SFSB.
> This can affect all BasicComponentInstance subclasses, but it is most noticeable for SFSBs due to the larger number of instances.
> The list of methods comes from ComponentConfiguration.getDefinedComponentMethods(), but I'm not sure if filtering the final methods out should be done there or an EJB-specific class since the rule about final methods is from the EJB spec. I'm also not sure if toString, equals and hashCode() should be treated as EJB business methods either.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (WFLY-3873) AJP-connector mangles SOAP-request
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3873?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3873:
--------------------------------------
This should be fixed, do you have any way of reproducing it?
> 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.1#6329)
11 years, 6 months
[JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4037:
--------------------------------------
It looks like an issue with clustered SSO
> Error 500 accessing png,css, rest
> ---------------------------------
>
> Key: WFLY-4037
> URL: https://issues.jboss.org/browse/WFLY-4037
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Marcial Atiénzar Navarro
> Assignee: Paul Ferraro
> Priority: Critical
>
> I've this error:
> {code}
> 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.get(CacheImpl.java:377)
> at org.infinispan.CacheImpl.get(CacheImpl.java:369)
> at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
> at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38)
> at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50)
> at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [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.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [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.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [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.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_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months