[JBoss JIRA] (WFLY-6294) Session draining always takes maximum configured timeout
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6294?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-6294:
--------------------------------------
Needs mod_cluster-core 1.3.3.Final (unreleased) upgrade.
> Session draining always takes maximum configured timeout
> --------------------------------------------------------
>
> Key: WFLY-6294
> URL: https://issues.jboss.org/browse/WFLY-6294
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Aaron Ogburn
> Assignee: Radoslav Husar
> Priority: Minor
>
> The mod_cluster session drain wait is not ending as expected. mod_cluster adds a session listener to be notified of session destruction. That is fired appropriately, but when the listener is invoked, the infinispan session manager still reports the session as active. Thus, this drain loop doesn't end after the notify because it still sees the active session:
> {code}
> while ((remainingSessions > 0) && (noTimeout || (timeout > 0))) {
> ModClusterLogger.LOGGER.drainSessions(remainingSessions, context.getHost(), context);
> listener.wait(noTimeout ? 0 : timeout);
> current = System.currentTimeMillis();
> timeout = end - current;
> remainingSessions = context.getActiveSessionCount();
> }
> {code}
> Can the listeners be invoked when the session is fully removed and no longer considered active?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1451) Unify/add unwrap methods to most of AttributeDefinition classes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1451?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1451:
------------------------------------------
This JIRA was partly sparked by a comment I made on https://github.com/wildfly/wildfly-core/pull/1470, where a newly introduced unwrap method didn't return null.
Tomaz replied mentioning that we already have some unwrap methods that don't return null, and the he'd filed this JIRA.
I think the goals of this JIRA are fine; i.e. that having unwrap functionality in other places sounds good, and that supporting null vs empty lists is good too.
I'm fine though with having existing methods retaining their current behavior (i.e. not returning null.) Really, changing that behavior should only be done with great care, as it's very likely an API break. Probably an overloaded or differently named method for the null/empty list/normal list 3 way behavior is better.
> Unify/add unwrap methods to most of AttributeDefinition classes
> ---------------------------------------------------------------
>
> Key: WFCORE-1451
> URL: https://issues.jboss.org/browse/WFCORE-1451
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> we now have unwrap method only on StringListAD and PropertiesAD. but there are handful of others that should have it to if possible.
> Thing to keep in mind is to make sure collection attributes can also return null as introduced in WFCORE-1448
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[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:
-----------------------------------------
OK you are right... I'm sorry for the confusion, client API doesn't matter. If TransportConstants.HTTP_UPGRADE_ENDPOINT_PROP_NAME is not set then delay occurs. It just reproduced if I commented out that property setting in your testcases.
> 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)
10 years
[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)
10 years
[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)
10 years
[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)
10 years
[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)
10 years
[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)
10 years
[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)
10 years
[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)
10 years