[JBoss JIRA] (WFLY-6413) Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
by Jason Holmberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-6413?page=com.atlassian.jira.plugin.... ]
Jason Holmberg commented on WFLY-6413:
--------------------------------------
Will this be fixed in the next release?
> Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-6413
> URL: https://issues.jboss.org/browse/WFLY-6413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0.0.Final
> Windows 7 or Mac 10.11.3
> Java 8
> Chrome, Firefox, Safari
> Reporter: Jason Holmberg
> Assignee: Stuart Douglas
> Priority: Blocker
>
> Safari on iOS requires range headers to be able to play video content via HTML5. So enabling range headers in WildFly should make this happen. It does not. Enabling the range headers actually prevent Chrome from playing the video content, which previously worked when the range headers were NOT enabled.
> After enabling range headers as described here:
> https://developer.jboss.org/message/953058#953058
> I made some range requests via `curl` to see what is being returned:
> This is the result of a request to *WildFly* with the Range headers enabled:
> {noformat}
> $ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT
> X-Powered-By: Undertow/1
> Server: WildFly/10
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 16:59:55 GMT
> {noformat}
> This is the result of a request to the same content being served from Tomcat 8, no special config required. *All the browsers can play the content when served from Tomcat 8*:
> {noformat}
> $ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4
> HTTP/1.1 206 Partial Content
> Server: Apache-Coyote/1.1
> Accept-Ranges: bytes
> ETag: W/"8200890-1458232627000"
> Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT
> Content-Range: bytes 0-8200889/8200890
> Content-Type: video/mp4
> Content-Length: 8200890
> Date: Fri, 18 Mar 2016 17:00:08 GMT
> {noformat}
> I have created a small project that I have been using to trouble shoot this issue: https://github.com/slowtrailrunner/html5-vidtest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2035) Util class tries to locate resource bundles using TCCL, which fails
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/JGRP-2035?page=com.atlassian.jira.plugin.... ]
Jason Greene commented on JGRP-2035:
------------------------------------
This commit is the problem: https://github.com/belaban/JGroups/commit/8bad26987223bda6e609127fdd39d05...
Can we get a release with this reverted?
As a general rule classes should always be loaded by the defining class loader (Class.forName() or OtherClass.class as the previous code before this change did).
There are a few special cases where you want to load classes from a TCCL, but those cases are where you expect classes other than your framework to be loaded (e.g. user classes defined in a different loader ), and when that approach is used it *must* be contextual. In other words, the code loading classes via TCCL needs to actually have a lifecycle. It's always wrong, for example, to load classes in the TCCL and stuff them in a static variable in a different class loader, as the life-cycles are not synchronized. Often times when TCCL support is truly required, you also have a set of local implementations, so in those cases you have to query multiple class loaders.
For more info see: https://developer.jboss.org/wiki/ModuleCompatibleClassloadingGuide
> Util class tries to locate resource bundles using TCCL, which fails
> -------------------------------------------------------------------
>
> Key: JGRP-2035
> URL: https://issues.jboss.org/browse/JGRP-2035
> Project: JGroups
> Issue Type: Bug
> Reporter: Jan Martiska
> Assignee: Bela Ban
> Priority: Blocker
>
> {{org.jgroups.util.Util}} class tries to locate jg-messages bundle using the TCCL, not its own class loader. In a Java SE environment, this typically doesn't matter, because the class loaders are the same, but in EAP, this means that jg-messages is sought by the class loader of the application rather than the class loader of JGroups module, which is obviously wrong. This is the offending line: https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> The call to getBundle fails with a MissingResourceException (see http://docs.oracle.com/javase/6/docs/api/java/util/ResourceBundle.html#ge...) and because this code is in a static initializer, the Util class becomes unusable.
> This causes Hibernate applications with 2LC infinispan clustering backend to not work.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-6420:
------------------------------
Attachment: artemis-hornetq-client.tgz
The attached project has tests using both JMS 1.1 and JMS 2.0 API.
Tests pass regardless the API that is used.
> 30secs delay on consumer.receive() in spite of shorter timeout
> --------------------------------------------------------------
>
> Key: WFLY-6420
> URL: https://issues.jboss.org/browse/WFLY-6420
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Tomohisa igarashi
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
> Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz, artemis-hornetq-client.tgz
>
>
> consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases.
> The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-6420 at 3/29/16 9:45 AM:
------------------------------------------------------------
The attached project has tests using both JMS 1.1 and JMS 2.0 API.
Tests pass regardless of the API that is used.
was (Author: jmesnil):
The attached project has tests using both JMS 1.1 and JMS 2.0 API.
Tests pass regardless the API that is used.
> 30secs delay on consumer.receive() in spite of shorter timeout
> --------------------------------------------------------------
>
> Key: WFLY-6420
> URL: https://issues.jboss.org/browse/WFLY-6420
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Tomohisa igarashi
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
> Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz, artemis-hornetq-client.tgz
>
>
> consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases.
> The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6349) JMSXGroupId has no effect on JMSProducer
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6349?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-6349.
-------------------------------
Fix Version/s: 10.1.0.Final
Resolution: Cannot Reproduce Bug
I have not been able to reproduce your issue with the latest WildFly master branch.
I modified the helloworld-mdb quickstart to set the JMSXGroupId (and Seq) on the producer and messages are received in the correct sequence by the same MDB:
{noformat}
15:27:51,765 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-97 (ActiveMQ-client-global-threads-2457283)) Received Message from queue: This is message 1
JMSXGroupID=sequential
JMSXDeliveryCount=1
foo=bar
JMSXGroupSeq=0
15:27:51,770 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-106 (ActiveMQ-client-global-threads-2457283)) Received Message from queue: This is message 2
JMSXGroupID=sequential
JMSXDeliveryCount=1
foo=bar
JMSXGroupSeq=1
15:27:51,771 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-110 (ActiveMQ-client-global-threads-2457283)) Received Message from queue: This is message 3
JMSXGroupID=sequential
JMSXDeliveryCount=1
foo=bar
JMSXGroupSeq=2
15:27:51,784 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-122 (ActiveMQ-client-global-threads-2457283)) Received Message from queue: This is message 4
JMSXGroupID=sequential
JMSXDeliveryCount=1
foo=bar
JMSXGroupSeq=3
15:27:51,785 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-129 (ActiveMQ-client-global-threads-2457283)) Received Message from queue: This is message 5
JMSXGroupID=sequential
JMSXDeliveryCount=1
foo=bar
JMSXGroupSeq=4
{noformat}
For reference, I've pushed the modified quickstart on GitHub: https://github.com/jmesnil/quickstart/tree/WFLY-6349_JMSXGroupId (relevant code snippets are https://github.com/jmesnil/quickstart/blob/WFLY-6349_JMSXGroupId/hellowor... and https://github.com/jmesnil/quickstart/blob/WFLY-6349_JMSXGroupId/hellowor...)
> JMSXGroupId has no effect on JMSProducer
> ----------------------------------------
>
> Key: WFLY-6349
> URL: https://issues.jboss.org/browse/WFLY-6349
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Harald Wellmann
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
>
> h3. Scenario
> I'm setting the {{JMSXGroupID}} on a {{JMSProducer}} to achieve message delivery in the correct order. The consumer is a message-driven bean.
> {code}
> JMSProducer producer = context.createProducer();
> producer = producer.setProperty("JMSXGroupID", "sequential");
> producer = producer.setProperty("foo", "bar");
> for (int i = 0; i < 50; i++) {
> msgNumber++;
> String text = "This is message " + msgNumber;
> producer.send(queue, text);
> }
> {code}
> h3. Expected Behaviour
> The messages are received in the correct order, the properties {{JMSXGroupID}} and {{foo}} are set on the receiver side.
> h3. Actual Behaviour
> The messages are received in random order. Property {{foo}} is set, but property {{JMSXGroupID}} is null on the receiver side.
> h3. Workaround
> Create a {{TextMessage}} and set the properties on the message, not on the producer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout
by Tomohisa igarashi (JIRA)
[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ]
Tomohisa igarashi commented on WFLY-6420:
-----------------------------------------
So your pom.xml has correct dependencies right? I tried my JMS 1.1 testcase *with your pom.xml* and it reproduces the issue.
> 30secs delay on consumer.receive() in spite of shorter timeout
> --------------------------------------------------------------
>
> Key: WFLY-6420
> URL: https://issues.jboss.org/browse/WFLY-6420
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Tomohisa igarashi
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
> Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz
>
>
> consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases.
> The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6420:
-----------------------------------
Using BOM means that you use the correct version of Artemis, Netty, etc.
The client can use either JMS 1.1 or JMS 2.0 API, that's not important. The key thing is to use the correct client libraries.
> 30secs delay on consumer.receive() in spite of shorter timeout
> --------------------------------------------------------------
>
> Key: WFLY-6420
> URL: https://issues.jboss.org/browse/WFLY-6420
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Tomohisa igarashi
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
> Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz
>
>
> consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases.
> The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout
by Tomohisa igarashi (JIRA)
[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ]
Tomohisa igarashi commented on WFLY-6420:
-----------------------------------------
No, using BOM doesn't solve the issue, just using JMS 2.0 way of client code (JMSContext) could get around the issue like I said in my previous comment. [~jmesnil] do you mean WildFly10 doesn't support JMS 1.1 client code (Connection/Session)?
> 30secs delay on consumer.receive() in spite of shorter timeout
> --------------------------------------------------------------
>
> Key: WFLY-6420
> URL: https://issues.jboss.org/browse/WFLY-6420
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Tomohisa igarashi
> Assignee: Jeff Mesnil
> Fix For: 10.1.0.Final
>
> Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz
>
>
> consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases.
> The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-4866) messaging-activemq: NPE when http-acceptor and https-acceptor configured
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4866?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-4866.
-------------------------------
Fix Version/s: 10.0.0.CR5
(was: 10.0.0.CR3)
Resolution: Done
Artemis underlying issue was fixed in Artemis 1.1.0.wildfly-009
> messaging-activemq: NPE when http-acceptor and https-acceptor configured
> ------------------------------------------------------------------------
>
> Key: WFLY-4866
> URL: https://issues.jboss.org/browse/WFLY-4866
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.1.0.Final, 10.0.0.CR2
> Environment: Windows 7 Pro, Java 7u55
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Labels: JMS, Messaging
> Fix For: 10.0.0.CR5
>
> Attachments: server-logs.zip
>
>
> With both an http-acceptor and an https-acceptor configured in the message subsystem, when an external Java app attempts to connect, it times out and the exception below appears in the server log.
> I tracked it down to the TransportConfigOperationHandlers.processAcceptors() method. At the end of the method, it creates a HashSet of the TransportConfiguration objects representing the acceptors. But, the TransportConfiguration equals() method reports that the https and http acceptors are equal, and as it is building a Set of unique values, the https-acceptor gets dropped.
> Later, when the http-upgrade handshake runs, the code is unable to find the https-acceptor, resulting in the NullPointerException.
> I think the fix might be to either not use a Set, or to look at the TransportConfiguration.equals() method.
> The workaround in the ticket works because the redundant <param> causes the equals() method to see the two acceptors as unequal.
> The exception was:
> [exec] 10:07:57,502 ERROR [org.xnio.listener] (default I/O-10) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:161)
> [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:153)
> [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:271)
> [exec] at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:221)
> [exec] at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1131)
> [exec] at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1351)
> [exec] at io.undertow.server.Connectors.terminateResponse(Connectors.java:78)
> [exec] at io.undertow.server.protocol.http.ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33)
> [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:273)
> [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:207)
> [exec] at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> [exec] at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> [exec] at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> [exec] at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
> [exec] at io.undertow.server.handlers.ProxyPeerAddressHandler.handleRequest(ProxyPeerAddressHandler.java:45)
> [exec] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
> [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-102) Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-102?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-102:
------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1299102|https://bugzilla.redhat.com/show_bug.cgi?id=1299102] from NEW to ASSIGNED
> Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-102
> URL: https://issues.jboss.org/browse/WFCORE-102
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha9
>
>
> The various base classes OSH authors use to create handlers force the author to deal with ServiceVerificationHandler and, during rollback, with removing any services the OSH added. This task is to have the OperationContext handle these things transparently, removing the need for authors to do so.
> To preserve compatibility, the various API methods authors may have overridden that expose the SVH and the list of added ServiceControllers will be retained (but deprecated), but the SVH and the list of handlers won't be used. The API javadoc will encourage use of method variants that don't use these parameters.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months