April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8632) Add jdbc-network-timeout attribute for messaging JDBC store

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8632?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-8632: ------------------------------ Summary: Add jdbc-network-timeout attribute for messaging JDBC store (was: Add) > Add jdbc-network-timeout attribute for messaging JDBC store > ----------------------------------------------------------- > > Key: WFLY-8632 > URL: https://issues.jboss.org/browse/WFLY-8632 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Martyn Taylor > Priority: Critical > Labels: KK-DR17, eap7.1-rfe-failure > > If the network goes down between Artemis and DB, the Artemis should behave in the same way as in case that journal storage is used and underlying network file system is disconnected. It should throw an critical IO error and stop itself. > Currently if network is down, JDBC calls hang until OS tcp timeout expires (typically 10 minutes). It contradicts fail fast pattern. > This behavior can be changed by setting networkTimeout \[1\] property to non zero value. I think this timeout should be configurable and default value should be less than 30 seconds what is default timeout for client's blocking operations. > If JDBC connection is closed from any reason (expiration of tcp timeout or networkTimeout), Artemis should throw critical IO error and stop itself. > Currently even if JDBC connection is closed, Artemis tries to execute DB operations on it what causes throwing of exceptions. Artemis is not able to recover from this state and it must be restarted. > *Customer impact:* If the network goes down between Artemis and DB, there is no error in server log for 10 minutes. During this time clients are blocked without any explanatory exception. It contradicts fail fast pattern and is difficult to find out what is wrong. > If JDBC connection is closed after 10 minutes, clients are still successfully connected to Artemis but they get exception for all operations. Since their connections are still active, they don't reconnect to other Artemis instance. > \[1\] https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#setNet... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8632) Artemis doesn't handle JDBC network problems

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8632?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-10497 to WFLY-8632: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8632 (was: JBEAP-10497) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) Affects Version/s: (was: 7.1.0.DR10) (was: 7.1.0.DR12) > Artemis doesn't handle JDBC network problems > -------------------------------------------- > > Key: WFLY-8632 > URL: https://issues.jboss.org/browse/WFLY-8632 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Martyn Taylor > Priority: Critical > Labels: KK-DR17, eap7.1-rfe-failure > > If the network goes down between Artemis and DB, the Artemis should behave in the same way as in case that journal storage is used and underlying network file system is disconnected. It should throw an critical IO error and stop itself. > Currently if network is down, JDBC calls hang until OS tcp timeout expires (typically 10 minutes). It contradicts fail fast pattern. > This behavior can be changed by setting networkTimeout \[1\] property to non zero value. I think this timeout should be configurable and default value should be less than 30 seconds what is default timeout for client's blocking operations. > If JDBC connection is closed from any reason (expiration of tcp timeout or networkTimeout), Artemis should throw critical IO error and stop itself. > Currently even if JDBC connection is closed, Artemis tries to execute DB operations on it what causes throwing of exceptions. Artemis is not able to recover from this state and it must be restarted. > *Customer impact:* If the network goes down between Artemis and DB, there is no error in server log for 10 minutes. During this time clients are blocked without any explanatory exception. It contradicts fail fast pattern and is difficult to find out what is wrong. > If JDBC connection is closed after 10 minutes, clients are still successfully connected to Artemis but they get exception for all operations. Since their connections are still active, they don't reconnect to other Artemis instance. > \[1\] https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#setNet... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8632) Add

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8632?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-8632: ------------------------------ Summary: Add (was: Artemis doesn't handle JDBC network problems) > Add > --- > > Key: WFLY-8632 > URL: https://issues.jboss.org/browse/WFLY-8632 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Martyn Taylor > Priority: Critical > Labels: KK-DR17, eap7.1-rfe-failure > > If the network goes down between Artemis and DB, the Artemis should behave in the same way as in case that journal storage is used and underlying network file system is disconnected. It should throw an critical IO error and stop itself. > Currently if network is down, JDBC calls hang until OS tcp timeout expires (typically 10 minutes). It contradicts fail fast pattern. > This behavior can be changed by setting networkTimeout \[1\] property to non zero value. I think this timeout should be configurable and default value should be less than 30 seconds what is default timeout for client's blocking operations. > If JDBC connection is closed from any reason (expiration of tcp timeout or networkTimeout), Artemis should throw critical IO error and stop itself. > Currently even if JDBC connection is closed, Artemis tries to execute DB operations on it what causes throwing of exceptions. Artemis is not able to recover from this state and it must be restarted. > *Customer impact:* If the network goes down between Artemis and DB, there is no error in server log for 10 minutes. During this time clients are blocked without any explanatory exception. It contradicts fail fast pattern and is difficult to find out what is wrong. > If JDBC connection is closed after 10 minutes, clients are still successfully connected to Artemis but they get exception for all operations. Since their connections are still active, they don't reconnect to other Artemis instance. > \[1\] https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#setNet... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8631) Integration test for WFCORE-2647 Add an option to always send the client SSL certificate to LDAP server

by Peter Palaga (JIRA)

Peter Palaga created WFLY-8631: ---------------------------------- Summary: Integration test for WFCORE-2647 Add an option to always send the client SSL certificate to LDAP server Key: WFLY-8631 URL: https://issues.jboss.org/browse/WFLY-8631 Project: WildFly Issue Type: Bug Reporter: Peter Palaga Assignee: Peter Palaga -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1225) Add options to specify the salience range of rules in a Decision Table Sheet

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1225?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1225: ------------------------------------- Documented by https://github.com/kiegroup/kie-docs/commit/f218baf0f8368bd9ae42dd44399ef... > Add options to specify the salience range of rules in a Decision Table Sheet > ---------------------------------------------------------------------------- > > Key: DROOLS-1225 > URL: https://issues.jboss.org/browse/DROOLS-1225 > Project: Drools > Issue Type: Feature Request > Components: decision tables > Affects Versions: 6.4.0.Final > Environment: any > Reporter: Osamu Kuniyasu > Assignee: Mario Fusco > Fix For: 7.0.0.Final > > > When we set Sequential=true in RuleSet properties. > The salience of the generated rules are started from 65518 and down one by one. > When we mix several Decision Table Sheets and DRL rules in a Ruleflow-Group (Agenda-Group), We could not make these rules' salience order, because each Decision Table Sheet has fixed to start from 65518. > A (limited) workaround is to have separated Ruleflow-Groups, > But this way does not solve the situation to back to the higher priority rules as it's previous Ruleflow-Group. > To solve The request is that add two options into RuleSet properties. like, > SequentialMaxPriority 10000 > SequentialMinPriority 1000 > By this optional properties, we can control the range of the salience of rules in the Decision Table Sheet. and it is possible safely to mix multiple Decision Table Sheets in a Ruleflow-Group. > The SequentialMaxPriority is used to set the start value of the salience instead of 65518. > The SequentialMinPriority is used to check if this minimum salience value is not violated in the Decision Table Compiler. (if it's violated, compilation error occurs.) > Best Regards, > Osamu Kuniyasu -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2716) ssl-context and authentication-context in Elytron dir-context should be mutually exclusive

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2716?page=com.atlassian.jira.plugi... ] Ondrej Lukas updated WFCORE-2716: --------------------------------- Description: To avoid possibility when two different ssl-contexts are configured in Elytron dir-context, its attributes {{ssl-context}} and {{authentication-context}} should be mutually exclusive. It is similar issue as WFCORE-2396. was:To avoid possibility when two different ssl-contexts are configured in Elytron dir-context, its attributes {{ssl-context}} and {{authentication-context}} should be mutually exclusive. > ssl-context and authentication-context in Elytron dir-context should be mutually exclusive > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2716 > URL: https://issues.jboss.org/browse/WFCORE-2716 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > To avoid possibility when two different ssl-contexts are configured in Elytron dir-context, its attributes {{ssl-context}} and {{authentication-context}} should be mutually exclusive. > It is similar issue as WFCORE-2396. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2716) ssl-context and authentication-context in Elytron dir-context should be mutually exclusive

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2716?page=com.atlassian.jira.plugi... ] Ondrej Lukas updated WFCORE-2716: --------------------------------- Affects Version/s: 3.0.0.Beta13 > ssl-context and authentication-context in Elytron dir-context should be mutually exclusive > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2716 > URL: https://issues.jboss.org/browse/WFCORE-2716 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > To avoid possibility when two different ssl-contexts are configured in Elytron dir-context, its attributes {{ssl-context}} and {{authentication-context}} should be mutually exclusive. > It is similar issue as WFCORE-2396. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2716) ssl-context and authentication-context in Elytron dir-context should be mutually exclusive

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFCORE-2716: ------------------------------------ Summary: ssl-context and authentication-context in Elytron dir-context should be mutually exclusive Key: WFCORE-2716 URL: https://issues.jboss.org/browse/WFCORE-2716 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical To avoid possibility when two different ssl-contexts are configured in Elytron dir-context, its attributes {{ssl-context}} and {{authentication-context}} should be mutually exclusive. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2715) principal and authentication-context in Elytron dir-context should be mutually exclusive

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2715?page=com.atlassian.jira.plugi... ] Ondrej Lukas updated WFCORE-2715: --------------------------------- Affects Version/s: 3.0.0.Beta13 > principal and authentication-context in Elytron dir-context should be mutually exclusive > ---------------------------------------------------------------------------------------- > > Key: WFCORE-2715 > URL: https://issues.jboss.org/browse/WFCORE-2715 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > To avoid possibility when two different principals are configured in Elytron dir-context, its attributes {{principal}} and {{authentication-context}} should be mutually exclusive. > It is similar issue as WFCORE-2396. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2715) principal and authentication-context in Elytron dir-context should be mutually exclusive

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFCORE-2715: ------------------------------------ Summary: principal and authentication-context in Elytron dir-context should be mutually exclusive Key: WFCORE-2715 URL: https://issues.jboss.org/browse/WFCORE-2715 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical To avoid possibility when two different principals are configured in Elytron dir-context, its attributes {{principal}} and {{authentication-context}} should be mutually exclusive. It is similar issue as JBEAP-8979. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 April 2017