September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1213) XA_RBEND should be included in check

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1213?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1213: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1147881|https://bugzilla.redhat.com/show_bug.cgi?id=1147881] from NEW to ASSIGNED > XA_RBEND should be included in check > ------------------------------------ > > Key: JBJCA-1213 > URL: https://issues.jboss.org/browse/JBJCA-1213 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.0.27.Final, 1.1.7.Final, 1.2.0.Beta4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.28.Final, 1.1.8.Final, 1.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1215) Only use XidWrapper if needed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1215?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1215: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1147881|https://bugzilla.redhat.com/show_bug.cgi?id=1147881] from NEW to ASSIGNED > Only use XidWrapper if needed > ----------------------------- > > Key: JBJCA-1215 > URL: https://issues.jboss.org/browse/JBJCA-1215 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.28.Final, 1.1.8.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1215) Only use XidWrapper if needed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1215?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1215: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1147719|https://bugzilla.redhat.com/show_bug.cgi?id=1147719] from NEW to MODIFIED > Only use XidWrapper if needed > ----------------------------- > > Key: JBJCA-1215 > URL: https://issues.jboss.org/browse/JBJCA-1215 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.28.Final, 1.1.8.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1215) Only use XidWrapper if needed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1215?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1215: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1147715|https://bugzilla.redhat.com/show_bug.cgi?id=1147715] from NEW to POST > Only use XidWrapper if needed > ----------------------------- > > Key: JBJCA-1215 > URL: https://issues.jboss.org/browse/JBJCA-1215 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.28.Final, 1.1.8.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1212) Pool could keep connections open after shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1212?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1212: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1054224|https://bugzilla.redhat.com/show_bug.cgi?id=1054224] from POST to MODIFIED > Pool could keep connections open after shutdown > ----------------------------------------------- > > Key: JBJCA-1212 > URL: https://issues.jboss.org/browse/JBJCA-1212 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.27.Final, 1.1.7.Final, 1.2.0.Beta4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.28.Final, 1.1.8.Final, 1.2.0.CR1 > > > Let MCP check pool status before scheduling prefill -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1139197|https://bugzilla.redhat.com/show_bug.cgi?id=1139197] from NEW to ASSIGNED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1886) CENTRAL_LOCK: provide option to make a node the lock owner instead of node:thread

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1886?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1886. ---------------------------- Resolution: Done > CENTRAL_LOCK: provide option to make a node the lock owner instead of node:thread > --------------------------------------------------------------------------------- > > Key: JGRP-1886 > URL: https://issues.jboss.org/browse/JGRP-1886 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6 > > > When using distributed locks, we currently use {{Owner}} as identity that holds a lock. {{Owner}} consists of the node's address and the thread's ID. > This has the same semantics as {{ReentrantLock}} which makes the thread which called {{Lock.lock()}} the owner. > However, in some scenarios, this is too strong and some applications only want the current node to be the lock owner. This is needed in cases where thread T1 locks a lock but thread T2 needs to unlock it. > This means, however, that all threads in a given node can lock or unlock the same lock. > h4. Solution > * Add property {{use_thread_id_for_lock_owner}} to {{CENTRAL_LOCK}} (default: false) > * When set, {{getOwner()}} sets the thread-id to -1 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1886) CENTRAL_LOCK: provide option to make a node the lock owner instead of node:thread

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1886?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1886: --------------------------- Description: When using distributed locks, we currently use {{Owner}} as identity that holds a lock. {{Owner}} consists of the node's address and the thread's ID. This has the same semantics as {{ReentrantLock}} which makes the thread which called {{Lock.lock()}} the owner. However, in some scenarios, this is too strong and some applications only want the current node to be the lock owner. This is needed in cases where thread T1 locks a lock but thread T2 needs to unlock it. This means, however, that all threads in a given node can lock or unlock the same lock. h4. Solution * Add property {{use_thread_id_for_lock_owner}} to {{CENTRAL_LOCK}} (default: false) * When set, {{getOwner()}} sets the thread-id to -1 was: When using distributed locks, we currently use {{Owner}} as identity that holds a lock. {{Owner}} consists of the node's address and the thread's ID. This has the same semantics as {{ReentrantLock}} which makes the thread which called {{Lock.lock()}} the owner. However, in some scenarios, this is too strong and some applications only want the current node to be the lock owner. This is needed in cases where thread T1 locks a lock but thread T2 needs to unlock it. This means, however, that all threads in a given node can lock or unlock the same lock. h4. Solution * Add property {{use_thread_id_for_lock_owner}} to {{CENTRAL_LOCK}} (default: false) * When set, {{getOwner()}} sets the thread-id to 0 > CENTRAL_LOCK: provide option to make a node the lock owner instead of node:thread > --------------------------------------------------------------------------------- > > Key: JGRP-1886 > URL: https://issues.jboss.org/browse/JGRP-1886 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6 > > > When using distributed locks, we currently use {{Owner}} as identity that holds a lock. {{Owner}} consists of the node's address and the thread's ID. > This has the same semantics as {{ReentrantLock}} which makes the thread which called {{Lock.lock()}} the owner. > However, in some scenarios, this is too strong and some applications only want the current node to be the lock owner. This is needed in cases where thread T1 locks a lock but thread T2 needs to unlock it. > This means, however, that all threads in a given node can lock or unlock the same lock. > h4. Solution > * Add property {{use_thread_id_for_lock_owner}} to {{CENTRAL_LOCK}} (default: false) > * When set, {{getOwner()}} sets the thread-id to -1 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1212) Pool could keep connections open after shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1212?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1212: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1054224|https://bugzilla.redhat.com/show_bug.cgi?id=1054224] from NEW to POST > Pool could keep connections open after shutdown > ----------------------------------------------- > > Key: JBJCA-1212 > URL: https://issues.jboss.org/browse/JBJCA-1212 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.27.Final, 1.1.7.Final, 1.2.0.Beta4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.28.Final, 1.1.8.Final, 1.2.0.CR1 > > > Let MCP check pool status before scheduling prefill -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1215) Only use XidWrapper if needed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1215?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1215: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1147419|https://bugzilla.redhat.com/show_bug.cgi?id=1147419] from NEW to POST > Only use XidWrapper if needed > ----------------------------- > > Key: JBJCA-1215 > URL: https://issues.jboss.org/browse/JBJCA-1215 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.28.Final, 1.1.8.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 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 September 2014