June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2172) Non-blocking flow control

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-2172?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on JGRP-2172: ----------------------------------- [~belaban] Yes, I think so. It's a bit tempting to exclude OOB messages from this rule, however I am afraid that this could lead to long message starvation: imagine that one long and many short messages are sent: it he big one does not have enough credits, it will wait. If the replenishment is not big enough to allow this long one to be sent as well, it will stay there - the short messages could cut their small portion of credits, though, but when another replenishement comes, since the credit count has dropped, there still won't be enough credits... > Non-blocking flow control > ------------------------- > > Key: JGRP-2172 > URL: https://issues.jboss.org/browse/JGRP-2172 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.4 > > > Sending a message through FlowControl (UFC, MFC) should not block if {{Message.Flag.NB_FC}} (non-blocking flow control) is set. > Instead, the message should be added to a queue (bounded if {{max_size}} > 0, else unbounded). The max queue size is given in bytes, so we can estimate what the memory penalty for reaching that size would be (if bounded). > The queued messages are sent when credits arrive. TBD: when credits arrive, should blocked threads or queued messages be released first? > Non-blocking flow control can be used by both external and internal threads. > If the queue is unbounded, then it is the responsibility of the application (e.g. Infinispan) to make sure the queue doesn't grow to an untenable size. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1251) Remove allow-all-sasl-mechanisms, allow-sasl-mechanisms and forbid-sasl-mechanisms from elytron-1_0.xsd

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1251?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1251: ------------------------------ Affects Version/s: 1.1.0.Beta52 > Remove allow-all-sasl-mechanisms, allow-sasl-mechanisms and forbid-sasl-mechanisms from elytron-1_0.xsd > ------------------------------------------------------------------------------------------------------- > > Key: ELY-1251 > URL: https://issues.jboss.org/browse/ELY-1251 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta52 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > In fix of JBEAP-11209, there were {{allow-all-sasl-mechanisms}}, {{allow-sasl-mechanisms}} and {{forbid-sasl-mechanisms}} removed from {{ElytronXmlParser}}. However these elements have not been removed from {{elytron-1_0.xsd}} file. They must be removed from that XSD file too. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1252) Revisit hashed-password and crypt-password credentials in Elytron client configuration file

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1252?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1252: ------------------------------ Affects Version/s: 1.1.0.Beta52 > Revisit hashed-password and crypt-password credentials in Elytron client configuration file > ------------------------------------------------------------------------------------------- > > Key: ELY-1252 > URL: https://issues.jboss.org/browse/ELY-1252 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta52 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > > Elytron client configuration file can include {{hashed-password}} or {{crypt-password}} as credentials for configuration. Internally this value is parsed in {{ElytronXmlParser}} and results to instance of {{PasswordSpec}}. However we do not see any SASL mechanism supported by Elytron which is able to work with it. > In case when {{hashed-password}} or {{crypt-password}} seems that cannot be actually used with Elytron then we suggest to remove elements {{hashed-password}} or {{crypt-password}} from Elytron client configuration file. Remove them also from elytron-1_0.xsd file. Otherwise please provide configuration which is able to work with {{hashed-password}} or {{crypt-password}} as credentials for configuration on client side. > We request blocker flag since configuration should not include elements which actually do nothing. Once we release them it can be hard to remove them in later application server version. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1252) Revisit hashed-password and crypt-password credentials in Elytron client configuration file

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-1252: --------------------------------- Summary: Revisit hashed-password and crypt-password credentials in Elytron client configuration file Key: ELY-1252 URL: https://issues.jboss.org/browse/ELY-1252 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Blocker Elytron client configuration file can include {{hashed-password}} or {{crypt-password}} as credentials for configuration. Internally this value is parsed in {{ElytronXmlParser}} and results to instance of {{PasswordSpec}}. However we do not see any SASL mechanism supported by Elytron which is able to work with it. In case when {{hashed-password}} or {{crypt-password}} seems that cannot be actually used with Elytron then we suggest to remove elements {{hashed-password}} or {{crypt-password}} from Elytron client configuration file. Remove them also from elytron-1_0.xsd file. Otherwise please provide configuration which is able to work with {{hashed-password}} or {{crypt-password}} as credentials for configuration on client side. We request blocker flag since configuration should not include elements which actually do nothing. Once we release them it can be hard to remove them in later application server version. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2975) Ctrl-s + any key leads to NPE

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2975?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-2975: -------------------------------------------- Assignee: Jean-Francois Denise > Ctrl-s + any key leads to NPE > ----------------------------- > > Key: WFCORE-2975 > URL: https://issues.jboss.org/browse/WFCORE-2975 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1251) Remove allow-all-sasl-mechanisms, allow-sasl-mechanisms and forbid-sasl-mechanisms from elytron-1_0.xsd

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-1251: --------------------------------- Summary: Remove allow-all-sasl-mechanisms, allow-sasl-mechanisms and forbid-sasl-mechanisms from elytron-1_0.xsd Key: ELY-1251 URL: https://issues.jboss.org/browse/ELY-1251 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical In fix of JBEAP-11209, there were {{allow-all-sasl-mechanisms}}, {{allow-sasl-mechanisms}} and {{forbid-sasl-mechanisms}} removed from {{ElytronXmlParser}}. However these elements have not been removed from {{elytron-1_0.xsd}} file. They must be removed from that XSD file too. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8955) Upgrade Artemis 1.5.5.jbossorg-003

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8955?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-11638 to WFLY-8955: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8955 (was: JBEAP-11638) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) (was: JMS) > Upgrade Artemis 1.5.5.jbossorg-003 > ----------------------------------- > > Key: WFLY-8955 > URL: https://issues.jboss.org/browse/WFLY-8955 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8732) IIOPNamingTestCase fails with ClassNotFoundException when building with JDK9

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-8732?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved WFLY-8732. --------------------------------- Resolution: Out of Date > IIOPNamingTestCase fails with ClassNotFoundException when building with JDK9 > ---------------------------------------------------------------------------- > > Key: WFLY-8732 > URL: https://issues.jboss.org/browse/WFLY-8732 > Project: WildFly > Issue Type: Bug > Components: EJB, IIOP > Reporter: Amos Feng > Assignee: Tomasz Adamski > > {noformat} > testIIOPNamingInvocation(org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase) Time elapsed: 0.004 sec <<< ERROR! > javax.naming.NoInitialContextException: Cannot instantiate class: com.sun.jndi.cosnaming.CNCtxFactory [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory] > at java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:719) > at java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305) > at java.naming/javax.naming.InitialContext.init(InitialContext.java:236) > at java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208) > at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:60) > {noformat} > I had tried to add "--add-modules=java.corba" in the testsuite/pom.xml. But it is still failed with NPE -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity

by Nuno Godinho de Matos (JIRA)

Nuno Godinho de Matos created WFLY-8954: ------------------------------------------- Summary: Wildfly 10 with eclipselink Onscucess observer gets stale entity Key: WFLY-8954 URL: https://issues.jboss.org/browse/WFLY-8954 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.0.0.Final Reporter: Nuno Godinho de Matos Hi, In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink. When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success. Then the observer will be working with stale entities that do not reflect the modifications done to the entity. A sample application for this issue is available in: https://github.com/99sono/wildfly10-observe-on-success-stale-entity The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation. Many thanks for taking a look. Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2172) Non-blocking flow control

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2172?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2172 at 6/19/17 4:59 AM: --------------------------------------------------------- [~rvansa] OK, makes sense not to interfere with the ordering of messages sent by the application. So the approach needs to be that - once queuing starts - *all* messages will be queued (regardless of size) and only when the queue is drained completely, can we start sending messages directly again. This prevents the P2-P1 scenario above. The transition to queuing and back needs to be atomic. was (Author: belaban): [~rvansa] OK, makes sense not to meddle the ordering of messages as sent by the application. So the approach needs to be that - once queuing starts - *all* messages will be queued (regardless of size) and only when the queue is drained completely, can we start sending messages directly again. This prevents the P2-P1 scenario above. The transition to queuing and back needs to be atomic. > Non-blocking flow control > ------------------------- > > Key: JGRP-2172 > URL: https://issues.jboss.org/browse/JGRP-2172 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.4 > > > Sending a message through FlowControl (UFC, MFC) should not block if {{Message.Flag.NB_FC}} (non-blocking flow control) is set. > Instead, the message should be added to a queue (bounded if {{max_size}} > 0, else unbounded). The max queue size is given in bytes, so we can estimate what the memory penalty for reaching that size would be (if bounded). > The queued messages are sent when credits arrive. TBD: when credits arrive, should blocked threads or queued messages be released first? > Non-blocking flow control can be used by both external and internal threads. > If the queue is unbounded, then it is the responsibility of the application (e.g. Infinispan) to make sure the queue doesn't grow to an untenable size. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2017