January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4764) NestedThrowable Class when accessed concurrently by 2 Threads cause deadlock .

by Vicky Kak (JIRA)

NestedThrowable Class when accessed concurrently by 2 Threads cause deadlock . ------------------------------------------------------------------------------ Key: JBAS-4764 URL: http://jira.jboss.com/jira/browse/JBAS-4764 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-3.2.8.SP1 Reporter: Vicky Kak Assigned To: Vicky Kak Fix For: JBossAS-4.2.2.GA http://forum.java.sun.com/thread.jspa?threadID=752201 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-3770) JBoss/JCA JDBC implementation should allow for Transaction isolation level to be reset on underlying JDBC connection prior to return to pool

by Weston Price (JIRA)

JBoss/JCA JDBC implementation should allow for Transaction isolation level to be reset on underlying JDBC connection prior to return to pool -------------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-3770 URL: http://jira.jboss.com/jira/browse/JBAS-3770 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Weston Price Assigned To: Weston Price Priority: Minor By default, when we return a JDBC connection to the pool we execute the following in the ManagedConnection.cleanup() method: if (jdbcTransactionIsolation != transactionIsolation) { try { con.setTransactionIsolation(jdbcTransactionIsolation); jdbcTransactionIsolation = transactionIsolation; } catch (SQLException e) { mcf.log.warn("Error resetting transaction isolation ", e); } } In this scenario we don't return the original isolation level on the underlying connection. The spec doesn't prohibit this, and I can't see any reason why we shouldn't do this, or provide a configurable option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-3440) HAPartitionImpl.viewAccepted should handle InterruptedException

by Brian Stansberry (JIRA)

HAPartitionImpl.viewAccepted should handle InterruptedException --------------------------------------------------------------- Key: JBAS-3440 URL: http://jira.jboss.com/jira/browse/JBAS-3440 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1 The JGroups up thread may throw an InterruptedException when the view change is placed in the handler's queue. This can only happen if the channel is being stopped, so if it happens, the exception should be caught and the view change should be ignored. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-5165) Generic ProxyFactoryHA too dependent on deployment ordering

by Brian Stansberry (JIRA)

Generic ProxyFactoryHA too dependent on deployment ordering ----------------------------------------------------------- Key: JBAS-5165 URL: http://jira.jboss.com/jira/browse/JBAS-5165 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 org.jboss.proxy.generic.ProxyFactoryHA will not signal its HATarget to allow invocations to proceed until it receives a JMS notification that its target service has started. But, if the target service starts before ProxyFactoryHA.create() is called, it will never get the notification. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-4893) JvmRouteValve (UseJK) for non session replication setup

by Takayoshi Kimura (JIRA)

JvmRouteValve (UseJK) for non session replication setup ------------------------------------------------------- Key: JBAS-4893 URL: http://jira.jboss.com/jira/browse/JBAS-4893 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Takayoshi Kimura Currently JBoss doesn't install JvmRouteValve for non session replication setup. However, it's still useful in the following scenario: * 1 Apache HTTPD frontend and 2 JBoss AS instances without session replication * A request goes JBoss node AAA (JSESSIONID=xxx.AAA) * The node AAA crashed * The request goes node BBB, lost session, recreate another * The node AAA recovered * The request comes back to the node AAA, lost session again Enabling JvmRouteValve can prevent last failure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAS-3556) Add non-integration based testing to cluster module

by Brian Stansberry (JIRA)

Add non-integration based testing to cluster module --------------------------------------------------- Key: JBAS-3556 URL: http://jira.jboss.com/jira/browse/JBAS-3556 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Test Suite Reporter: Brian Stansberry All the unit tests for the AS cluster module are run via the testsuite tests-clustering target, which starts two AS instances. This is painful and time consuming and discourages writing of simple unit tests that exercise a particular class, with no need for a larger integration. Need to set up a src/tests tree in the cluster module, add simple unit tests to it, and integrate that into the overall testsuite run. The security module has this kind of setup; look to that to see how the overall testsuite integration is done. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JGRP-646) ConnectionTable problem after a while in 2 node cluster

by Martin Vecera (JIRA)

ConnectionTable problem after a while in 2 node cluster ------------------------------------------------------- Key: JGRP-646 URL: http://jira.jboss.com/jira/browse/JGRP-646 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP4 Environment: Two physical machines both running RHEL5, Sun JVM 1.5.0_12, full SOA-P 4.2.0.IR8 based on EAP 4.3.0.GA (build: SVNTag=JBPAPP_4_3_0_GA date=200711291835), Orcale DB on a separate machine Reporter: Martin Vecera Assigned To: Bela Ban Reproducible: 100% 1. I took full IR8 and used dbinstall (https://svn.corp.jboss.com/repos/soa/trunk/qa/dbinstall/) for the 'all' configuration to use Oracle DB. 2. I unsecured jmx-service-invoker. 3. I copied the SOA-P to the second node. 4. I changed the server peer id on the both copies to be different. 5. I started the first node, it was successful. 6. I started the second node successfully as well. 7. I let it be for half an hour. 8. This appeared in the log files: Node 1: 2007-12-13 10:57:07,502 WARN [org.jgroups.blocks.ConnectionTable] peer closed connection, trying to re-send msg 2007-12-13 10:57:07,502 ERROR [org.jgroups.blocks.ConnectionTable] 2nd attempt to send data failed too Node 2: 2007-12-13 10:57:08,927 WARN [org.jgroups.blocks.ConnectionTable] peer closed connection, trying to re-send msg 2007-12-13 10:57:08,928 ERROR [org.jgroups.blocks.ConnectionTable] 2nd attempt to send data failed too It doesn't seem like there's anything related to the problems in the logs (no exceptions, no other JGroups related output...). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-3632) Too early checking of not closing connections

by Adrian Brock (JIRA)

Too early checking of not closing connections --------------------------------------------- Key: JBAS-3632 URL: http://jira.jboss.com/jira/browse/JBAS-3632 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.5.CR1 Reporter: Adrian Brock Assigned To: Weston Price Priority: Minor In the case where a transaction is ended early, e.g. JBossTM rollsback transactions at a timeout immediately, the cached connection manager is firing connection not closed events. This is because the ejb is still in the invocation with the connection open but the transaction synchronization is fired by the rollback/timeout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

5
11
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1819) WSDL status should be persisted in the database for better handling

by Chris Laprun (JIRA)

WSDL status should be persisted in the database for better handling ------------------------------------------------------------------- Key: JBPORTAL-1819 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1819 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal WSRP Affects Versions: 2.6.3 Final Reporter: Chris Laprun Assigned To: Chris Laprun Fix For: 2.8 Final -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4531) AsynchEventHandler should ignore queueEvent calls when stopped

by Brian Stansberry (JIRA)

AsynchEventHandler should ignore queueEvent calls when stopped -------------------------------------------------------------- Key: JBAS-4531 URL: http://jira.jboss.com/jira/browse/JBAS-4531 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.CR1 AsynchEventHandler.queueEvent should not add events to its queue when it is stopped. If an event is added after stop() is called, it can sit there for a long period and then be handled if start() is called again. This could happen during a stop/start cycling of the HAPartition. This happens now with a MuxChannel that gets a viewAccepted as part of disconnecting -- ClusterPartition ends up putting an event in the stopped queue. That particular issue may go away if JGroups decides to not issue the view, but we should be sure to handle such a case properly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
5
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 January 2008