[JBoss JIRA] (WFLY-4712) Old session id in request crashes servlet handler before reaching rest endpoint
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4712?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4712:
------------------------------------
Assignee: Paul Ferraro (was: Stuart Douglas)
> Old session id in request crashes servlet handler before reaching rest endpoint
> -------------------------------------------------------------------------------
>
> Key: WFLY-4712
> URL: https://issues.jboss.org/browse/WFLY-4712
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Clustering, Web (Undertow), Web Services
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: SmartOS, CentOS 7, Oracle JDK 7
> Reporter: Michael Noack
> Assignee: Paul Ferraro
> Priority: Critical
>
> Clients with old/wrong JSESSIONIDs in requests will get a 500 internal server error. The rest endpoint they call won't be reached, even if no session information is required to process the request.
> This is particularly annoying in A/B-deployments where two or more server-groups are used for role-out of new deployments of the same web application. Clients that are connected to "server-group A" will get a 500 for their request, once the load-balancer switches them to "server-group B".
> 2015-06-01 12:37:19,642 ERROR [io.undertow.request] (default task-339) UT005023: Exception handling request to /myApp/status: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:319)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:308)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:163)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:688) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:364) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:212) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:160) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:260) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0-internal]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0-internal]
> 2015-06-01 12:37:19,648 ERROR [io.undertow.servlet.request] (default task-339) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.NullPointerException
> at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:71) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.context.http.HttpRequestContextImpl.deactivate(HttpRequestContextImpl.java:72) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:282) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:143) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:304) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0-internal]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0-internal]
> The expected behavior is that:
> A) wildfly should simply create a new session (which it already does)
> B) wildfly should process the request as if the user came with no session information at all (instead of returning a 500 server error)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4712) Old session id in request crashes servlet handler before reaching rest endpoint
by Michael Noack (JIRA)
Michael Noack created WFLY-4712:
-----------------------------------
Summary: Old session id in request crashes servlet handler before reaching rest endpoint
Key: WFLY-4712
URL: https://issues.jboss.org/browse/WFLY-4712
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, Clustering, Web (Undertow), Web Services
Affects Versions: 8.2.0.Final, 8.1.0.Final
Environment: SmartOS, CentOS 7, Oracle JDK 7
Reporter: Michael Noack
Assignee: Stuart Douglas
Priority: Critical
Clients with old/wrong JSESSIONIDs in requests will get a 500 internal server error. The rest endpoint they call won't be reached, even if no session information is required to process the request.
This is particularly annoying in A/B-deployments where two or more server-groups are used for role-out of new deployments of the same web application. Clients that are connected to "server-group A" will get a 500 for their request, once the load-balancer switches them to "server-group B".
2015-06-01 12:37:19,642 ERROR [io.undertow.request] (default task-339) UT005023: Exception handling request to /myApp/status: java.lang.NullPointerException
at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:319)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:308)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:163)
at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:688) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:364) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:212) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:160) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:260) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0-internal]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0-internal]
2015-06-01 12:37:19,648 ERROR [io.undertow.servlet.request] (default task-339) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.NullPointerException
at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:71) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.context.http.HttpRequestContextImpl.deactivate(HttpRequestContextImpl.java:72) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:282) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:143) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:304) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0-internal]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0-internal]
The expected behavior is that:
A) wildfly should simply create a new session (which it already does)
B) wildfly should process the request as if the user came with no session information at all (instead of returning a 500 server error)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4711) Invalid Last-Modified header
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-4711:
------------------------------------
Summary: Invalid Last-Modified header
Key: WFLY-4711
URL: https://issues.jboss.org/browse/WFLY-4711
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final
Environment: Windows Server 2008
Reporter: Davy De Durpel
Assignee: Stuart Douglas
After 2 months of use Wildfly suddenly started to send an invalid Last-Modified header. Normally it should be in the format:
Fri, 10 Oct 2014 19:35:55 GMT
But sometimes it sends:
Fri, 10 Oct 2014 21:35:55 CEST
Or even:
Fri, 10 Oct 2014 21:35:55 CEST GMT
The URLConnection.getLastModified() method cannot handle these 2 last formats as it uses an old and deprecated Date.parse(..) method.
A restart of the service fixes the issue for a few hours after which it reappears but not for all requests. We switched back to JBoss 7.1.1 and the issue disappeared completely so we're pretty sure that it's a bug in WildFly. No updates were done to windows, java and Wildfly that could have triggered the issue. We noticed the issue because we have a java applet running at the customer side. We use URLConnection to download some files based on the last modification date of these files. Browsers don't seem to be affected by the issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFCORE-725) Remove ClassIndex from the server module
by Stuart Douglas (JIRA)
Stuart Douglas created WFCORE-725:
-------------------------------------
Summary: Remove ClassIndex from the server module
Key: WFCORE-725
URL: https://issues.jboss.org/browse/WFCORE-725
Project: WildFly Core
Issue Type: Task
Components: Server
Reporter: Stuart Douglas
Assignee: Stuart Douglas
ClassIndex is only used in a couple of places, and it is confusing to have two different indexes. It should be merged into ClassReflectionIndex.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4710) Upgrade to Beanutils 1.9.2
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-4710:
---------------------------------
Summary: Upgrade to Beanutils 1.9.2
Key: WFLY-4710
URL: https://issues.jboss.org/browse/WFLY-4710
Project: WildFly
Issue Type: Component Upgrade
Affects Versions: 10.0.0.Alpha2
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 10.0.0.Alpha3
Apache ActiveMQ Artemis depends on Beanutils 1.9.2 and its BeanIntrospector
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4709) Invalid Last-Modified header
by Davy De Durpel (JIRA)
[ https://issues.jboss.org/browse/WFLY-4709?page=com.atlassian.jira.plugin.... ]
Davy De Durpel commented on WFLY-4709:
--------------------------------------
Until now the issue only occured on our customers' production environment. We haven't been able to reproduce it on their test environments.
Our customer does not allow me to update WildFly in the production environment at this moment. By the end of this week I will deploy a patch of our applet
If this workaround works than we are allowed to do a (temporary) update to WildFly 9 CR1. I can't say when exactly this will be done but I think that it will be in the second half of june.
One other important remarkt though. When the issue occurs it's not for all the requests. Some are good and some are bad. This seems to indicate that the issue is linked to a web socket (thread).
> Invalid Last-Modified header
> ----------------------------
>
> Key: WFLY-4709
> URL: https://issues.jboss.org/browse/WFLY-4709
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Windows Server 2008
> Reporter: Davy De Durpel
> Assignee: Stuart Douglas
>
> After 2 months of use Wildfly suddenly started to send an invalid Last-Modified header. Normally it should be in the format:
> Fri, 10 Oct 2014 19:35:55 GMT
> But sometimes it sends:
> Fri, 10 Oct 2014 21:35:55 CEST
> Or even:
> Fri, 10 Oct 2014 21:35:55 CEST GMT
> The URLConnection.getLastModified() method cannot handle these 2 last formats as it uses an old and deprecated Date.parse(..) method.
> A restart of the service fixes the issue for a few hours after which it reappears but not for all requests. We switched back to JBoss 7.1.1 and the issue disappeared completely so we're pretty sure that it's a bug in WildFly. No updates were done to windows, java and Wildfly that could have triggered the issue. We noticed the issue because we have a java applet running at the customer side. We use URLConnection to download some files based on the last modification date of these files. Browsers don't seem to be affected by the issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4709) Invalid Last-Modified header
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4709?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4709:
-----------------------------------
Can this be reproduced also on WildFly 9 CR1?
> Invalid Last-Modified header
> ----------------------------
>
> Key: WFLY-4709
> URL: https://issues.jboss.org/browse/WFLY-4709
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Windows Server 2008
> Reporter: Davy De Durpel
> Assignee: Stuart Douglas
>
> After 2 months of use Wildfly suddenly started to send an invalid Last-Modified header. Normally it should be in the format:
> Fri, 10 Oct 2014 19:35:55 GMT
> But sometimes it sends:
> Fri, 10 Oct 2014 21:35:55 CEST
> Or even:
> Fri, 10 Oct 2014 21:35:55 CEST GMT
> The URLConnection.getLastModified() method cannot handle these 2 last formats as it uses an old and deprecated Date.parse(..) method.
> A restart of the service fixes the issue for a few hours after which it reappears but not for all requests. We switched back to JBoss 7.1.1 and the issue disappeared completely so we're pretty sure that it's a bug in WildFly. No updates were done to windows, java and Wildfly that could have triggered the issue. We noticed the issue because we have a java applet running at the customer side. We use URLConnection to download some files based on the last modification date of these files. Browsers don't seem to be affected by the issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFCORE-724) CLI throws IAE on tab completion
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-724?page=com.atlassian.jira.plugin... ]
Petr Kremensky moved JBEAP-229 to WFCORE-724:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-724 (was: JBEAP-229)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 2.0.0.Alpha3
(was: EAP 7.0.0.DR2)
Component/s: CLI
(was: CLI)
Target Release: (was: EAP 7.0.0.GA)
> CLI throws IAE on tab completion
> --------------------------------
>
> Key: WFCORE-724
> URL: https://issues.jboss.org/browse/WFCORE-724
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha3
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> CLI throws IAE on tab completion.
> https://issues.jboss.org/browse/WFCORE-672 - CLI tab-completion for attribute name path syntax
> {noformat}
> [standalone@localhost:9990 /] /subsystem=jgroups/stack=udp/transport=UDP:write-attribute(name=properties.java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:136)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1373)
> at org.jboss.as.cli.impl.AttributeNamePathCompleter$AttributeNamePathCallbackHandler.getCandidates(AttributeNamePathCompleter.java:165)
> at org.jboss.as.cli.impl.AttributeNamePathCompleter.complete(AttributeNamePathCompleter.java:112)
> at org.jboss.as.cli.impl.AttributeNamePathCompleter.complete(AttributeNamePathCompleter.java:96)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:229)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:73)
> at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:126)
> at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63)
> at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:122)
> at org.jboss.aesh.console.Console.complete(Console.java:1227)
> at org.jboss.aesh.console.Console.parseOperation(Console.java:551)
> at org.jboss.aesh.console.Console.read(Console.java:453)
> at org.jboss.aesh.console.Console.read(Console.java:347)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:198)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1327)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:272)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.modules.Module.run(Module.java:308)
> at org.jboss.modules.Main.main(Main.java:487)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4709) Invalid Last-Modified header
by Davy De Durpel (JIRA)
Davy De Durpel created WFLY-4709:
------------------------------------
Summary: Invalid Last-Modified header
Key: WFLY-4709
URL: https://issues.jboss.org/browse/WFLY-4709
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final
Environment: Windows Server 2008
Reporter: Davy De Durpel
Assignee: Stuart Douglas
After 2 months of use Wildfly suddenly started to send an invalid Last-Modified header. Normally it should be in the format:
Fri, 10 Oct 2014 19:35:55 GMT
But sometimes it sends:
Fri, 10 Oct 2014 21:35:55 CEST
Or even:
Fri, 10 Oct 2014 21:35:55 CEST GMT
The URLConnection.getLastModified() method cannot handle these 2 last formats as it uses an old and deprecated Date.parse(..) method.
A restart of the service fixes the issue for a few hours after which it reappears but not for all requests. We switched back to JBoss 7.1.1 and the issue disappeared completely so we're pretty sure that it's a bug in WildFly. No updates were done to windows, java and Wildfly that could have triggered the issue. We noticed the issue because we have a java applet running at the customer side. We use URLConnection to download some files based on the last modification date of these files. Browsers don't seem to be affected by the issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (WFLY-4627) Issue when connecting to JBoss 7.1.1 queues installed in Linux from custom application installed in HP-UX
by Carmen Rodriguez Leon (JIRA)
[ https://issues.jboss.org/browse/WFLY-4627?page=com.atlassian.jira.plugin.... ]
Carmen Rodriguez Leon commented on WFLY-4627:
---------------------------------------------
Hello,
Any news on this issue?
Regards.
> Issue when connecting to JBoss 7.1.1 queues installed in Linux from custom application installed in HP-UX
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4627
> URL: https://issues.jboss.org/browse/WFLY-4627
> Project: WildFly
> Issue Type: Bug
> Environment: JBoss AS 7.1.1
> JDK: 1.6.0_13
> Operating System: Linux
> Reporter: Carmen Rodriguez Leon
> Assignee: Jason Greene
>
> I have a JBoss AS 7.1.1 deployed in a machine with the environment detailed above. In this JBoss I have 4 queues deployed.
> I run Jboss as follows:
> ./standalone.sh -c standalone-full.xml -b xxx.xxx.xx.xxx -bmanagement=xxx.xxx.xx.xxx &
> I have successfully connected HermesJMS from a remote machine (also using Linux) to the JBoss queues.
> However, when I try to connect to the queues from a custom application hosted in a remote machine using HP-UX, I get the following error:
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:615)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:121)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:116)
> Caused by: HornetQException[errorCode=2 message=Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:619)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:611)
> ... 6 more
> I'm quite sure that it is not a connectivity issue because if I configure a wrong username/password it says: Invalid username or password so it's connecting properly to JBoss. The problem is when connecting to the queues.
> Regarding the configuration of our custom application, it is exactly the same than the one used in HermesJMS (also the same libraries), so it should be ok as HermesJMS connects properly.
> The only difference is in the Operating System: JBoss and HermesJMS are installed in Linux while our custom application is installed in HP-UX. May this be an issue?
> Regards
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months