March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6435) Upgrade JGroups to 3.6.9.Final

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-6435: ---------------------------------- Summary: Upgrade JGroups to 3.6.9.Final Key: WFLY-6435 URL: https://issues.jboss.org/browse/WFLY-6435 Project: WildFly Issue Type: Component Upgrade Components: Clustering Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Blocker Fix For: 10.1.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2035) Util class tries to locate resource bundles using TCCL, which fails

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-2035?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated JGRP-2035: ------------------------------- Affects Version/s: 3.6.8 > 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 > Affects Versions: 3.6.8 > 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)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2035) Util class tries to locate resource bundles using TCCL, which fails

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-2035?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned JGRP-2035: ---------------------------------- Assignee: Paul Ferraro (was: Bela Ban) > 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 > Affects Versions: 3.6.8 > Reporter: Jan Martiska > Assignee: Paul Ferraro > 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)

6 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1318) list driven ExceptionSorter, StaleConnectionChecker

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1318?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1318: ----------------------------------- Fix Version/s: WildFly/IronJacamar 1.3.4.Final 1.0.37.Final > list driven ExceptionSorter, StaleConnectionChecker > --------------------------------------------------- > > Key: JBJCA-1318 > URL: https://issues.jboss.org/browse/JBJCA-1318 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Reporter: Johnathon Lee > Assignee: Johnathon Lee > Priority: Minor > Fix For: WildFly/IronJacamar 1.3.4.Final, 1.0.37.Final, 1.2.8.Final > > > Configuration defined ExceptionSorter, StaleConnectionChecker. > Using an externally (from the implementation) defined "," separated list. > Defined via '<config-property name=prop_name >value1,value2,value3</>' in the standalone/domain configuration files. > ie: > set via <config-property name="FatalExceptions">10099,10100,10101</> > set via <config-property name="StaleExceptions">10099,10100,10101</> > Documentation updated to reflect suggested error codes for vendor based upon the current implementations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

6 years, 12 months

1
0
0 / 0

[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)

6 years, 12 months

1
0
0 / 0

[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)

6 years, 12 months

1
0
0 / 0

[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)

6 years, 12 months

1
0
0 / 0

[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)

6 years, 12 months

1
0
0 / 0

[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)

6 years, 12 months

1
0
0 / 0

[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)

6 years, 12 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016