[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)
10 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)
10 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)
10 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)
10 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)
10 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)
10 years, 11 months
[JBoss JIRA] (WFLY-3439) Websockets not working
by Kadhem Kacem (JIRA)
[ https://issues.jboss.org/browse/WFLY-3439?page=com.atlassian.jira.plugin.... ]
Kadhem Kacem commented on WFLY-3439:
------------------------------------
Ok Tomaz i will do, thank you.
> Websockets not working
> ----------------------
>
> Key: WFLY-3439
> URL: https://issues.jboss.org/browse/WFLY-3439
> Project: WildFly
> Issue Type: Bug
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Reporter: Veli Cris
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> Hi,
> I deployed a .war file containing a single endpoint definition (Websocket). I can see following lines in console but nothing happens when trying to open connection from a websocket client. Same .war deployed in WildFly 8.0.0 is working. Please investigate!
> The configuration is standalone.
> [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /0.0.0.0:8080
> [io.undertow.websockets.jsr] (MSC service thread 1-4) UT026003: Adding annotated server endpoint ...
> [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017534: Registered web context: ...
> [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "web.war" (runtime-name : "web.war")
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-3439) Websockets not working
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3439?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3439:
-----------------------------------
[~kadhem] please start a new forum thread in https://community.jboss.org/en/wildfly and describe your application what is doing and how.
also adding info about your deployment jars (WEB-INF/lib) would be helpful
> Websockets not working
> ----------------------
>
> Key: WFLY-3439
> URL: https://issues.jboss.org/browse/WFLY-3439
> Project: WildFly
> Issue Type: Bug
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Reporter: Veli Cris
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> Hi,
> I deployed a .war file containing a single endpoint definition (Websocket). I can see following lines in console but nothing happens when trying to open connection from a websocket client. Same .war deployed in WildFly 8.0.0 is working. Please investigate!
> The configuration is standalone.
> [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /0.0.0.0:8080
> [io.undertow.websockets.jsr] (MSC service thread 1-4) UT026003: Adding annotated server endpoint ...
> [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017534: Registered web context: ...
> [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "web.war" (runtime-name : "web.war")
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4696) OutOfMemory DirectByteBuffer XNIO
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4696?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4696:
--------------------------------------
That stack trace looks like it is from 8.1.0.Final, and a lot of the code has changed in that version. Can you post a more up to date stack trace?
> OutOfMemory DirectByteBuffer XNIO
> ---------------------------------
>
> Key: WFLY-4696
> URL: https://issues.jboss.org/browse/WFLY-4696
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Carlos Rodríguez Aguado
> Assignee: Stuart Douglas
> Priority: Blocker
>
> I get this errors constantly in my server when a web connection is interrupted from the browser for instance:
> 11:50:45,301 ERROR [stderr] (default task-339) Exception in thread "default task-339" java.nio.BufferOverflowException
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:150)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpResponseConduit.java:629)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:205)
> 11:50:45,301 ERROR [stderr] (default task-339) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:201)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.lang.Thread.run(Thread.java:745)
> And then, I think this errors lead to a OutOfMemory crash:
> 14:23:09,592 ERROR [org.xnio.listener] (default I/O-3) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:143) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> I also have found that if I perform a full GC manually the server recovers, but it can not recover by itself, by performing other types of GCs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFCORE-723) Support for -P multiple times
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-723?page=com.atlassian.jira.plugin... ]
Tomaz Cerar reassigned WFCORE-723:
----------------------------------
Assignee: James Perkins (was: Jason Greene)
it is possible it broke with migration to launcher api
> Support for -P multiple times
> -----------------------------
>
> Key: WFCORE-723
> URL: https://issues.jboss.org/browse/WFCORE-723
> Project: WildFly Core
> Issue Type: Feature Request
> Affects Versions: 1.0.0.CR5
> Reporter: John Ament
> Assignee: James Perkins
>
> In 8.2.0 and 8.1, we had the ability to invoke (in an arquilian test in my case) the startup with -P multiple times, e.g.
> {code}
> -P=../standalone/configuration/dev.properties -P=../standalone/configuration/integ.properties -P=../standalone/configuration/custom.properties
> {code}
> This doesn't seem to work in WF 9 CR1. It seems like only the last option is read.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months