May 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-199) AOP-based version of FirstAvailable that checks invocatio metadata for initial target

by Brian Stansberry (JIRA)

AOP-based version of FirstAvailable that checks invocatio metadata for initial target ------------------------------------------------------------------------------------- Key: JBCLUSTER-199 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-199 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Components: HA-Client Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 1.1.0.GA For EJBTHREE-1375. The proxy knows the target it comes from and puts that in the invocation metadata. LBP should use that target if it hasn't already selected one. -- 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

18 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBXB-143) Invalid marshalling of dateTime Timezone

by Darran Lofthouse (JIRA)

Invalid marshalling of dateTime Timezone ---------------------------------------- Key: JBXB-143 URL: http://jira.jboss.com/jira/browse/JBXB-143 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-1.0.0.SP2, JBossXB-2.0.0.CR9 Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: JBossXB-2.0.0.CR10, JBossXB-1.0.0.SP3 The following class: - http://anonsvn.jboss.org/repos/common/jbossxb/trunk/src/main/java/org/jbo... Converts the timezone to a String as: - private static String marshalTimeZone(Calendar value) { int offset = value.get(Calendar.ZONE_OFFSET) + value.get(Calendar.DST_OFFSET); if(offset == 0) { return "Z"; } DecimalFormat hourFormat = new DecimalFormat("'+'00;-00"); DecimalFormat minuteFormat = new DecimalFormat("00"); int minutes = offset / (1000 * 60); int hours = minutes / 60; minutes -= (hours * 60); return hourFormat.format(hours) + ":" + minuteFormat.format(minutes); } The get methods return a time in milliseconds but the code assumes it is returned in hours. -- 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

18 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBXB-142) SoapEncUnitTestCase - Incorrect Timezone Handling

by Darran Lofthouse (JIRA)

SoapEncUnitTestCase - Incorrect Timezone Handling ------------------------------------------------- Key: JBXB-142 URL: http://jira.jboss.com/jira/browse/JBXB-142 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-1.0.0.SP2, JBossXB-2.0.0.CR9 Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: JBossXB-2.0.0.CR10, JBossXB-1.0.0.SP3 The testcase SoapEncUnitTestCase uses incorrect timezone handling. The following code is within the instantiation of the object being marshalled: - Calendar varDateTime = (Calendar)new GregorianCalendar(96, 5, 1); int offset = varDateTime.get(Calendar.ZONE_OFFSET) + varDateTime.get(Calendar.DST_OFFSET); StringBuffer buf = new StringBuffer(); buf.append("GMT"); if(offset > 0) { buf.append('+'); } buf.append(offset); varDateTime.setTimeZone(TimeZone.getTimeZone(buf.toString())); struct.setVarDateTime(varDateTime); 1 - The year is 96 not 1996 so this is before DST offsets began. 2 - The two gets return an offset in milliseconds but the code assumes it is in hours. 3 - The TimeZone.getTimeZone is being passed a "GMT+3600000" this is not understood so GMT is returned by default. When this test case is executed in CEST the setTimeZone changes the time to: - <varDateTime>0096-05-31T23:00:00.000Z</varDateTime> This is expected in the resulting XML. For portability the Calendar instances needs to be constructed in a way to avoid the users timezone affecting the outcome i.e. varDateTime should be constructed have the timezone set to GMT and then set the exact time. -- 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

18 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-750) Deadlock between GroupRequest and FLUSH during concurrent startup.

by Robert Newson (JIRA)

Deadlock between GroupRequest and FLUSH during concurrent startup. ------------------------------------------------------------------ Key: JGRP-750 URL: http://jira.jboss.com/jira/browse/JGRP-750 Project: JGroups Issue Type: Bug Affects Versions: 2.6.3 Environment: Debian etch (i386), Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode) Reporter: Robert Newson Assigned To: Bela Ban We've been having more trouble with concurrent start up and now think we've isolated a deadlock between FLUSH and GroupRequest during concurrent startup. We have four boxes that join a channel and use MessageDispatcher immediately after connecting. This frequently blocks indefinitely. GroupRequest.execute() obtains a lock, then a subsequent view change comes in which does likewise. The upshot is that we can see all Incoming threads are blocked for the lock and the only way it can be released is for a stop_flush message to occur. With all incoming threads blocked, that never happens. In the attached unit test if you add this after the call to connect("A"), it passes, implying a deadlock; if (j ==0) { Thread.sleep(500); } Additionally, and this is more speculative, it seems the wait/notify code in pbcast does not account for the spurious wakeup case. I don't know under what circumstances they happen, and I don't believe we're seeing spurious wakes at this time, but it should be fixed at some stage. -- 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

18 years, 2 months

4
13
0 / 0

[JBoss JIRA] Created: (JGRP-748) Change in start() and connect() introduced new bug in the shared transport

by Bela Ban (JIRA)

Change in start() and connect() introduced new bug in the shared transport -------------------------------------------------------------------------- Key: JGRP-748 URL: http://jira.jboss.com/jira/browse/JGRP-748 Project: JGroups Issue Type: Sub-task Reporter: Bela Ban Assigned To: Bela Ban [Vladimir] This change caused SharedTransportTest#testReferenceCounting to start failing. As soon as one channel sharing transport layer calls disconnect we shut down threads receiving packets. Can you access JIRA and cvs. Both are not working for me! Vladimir Bela Ban wrote: > User: belaban Date: 08/04/23 02:21:53 > > Modified: src/org/jgroups/protocols Tag: Branch_JGroups_2_6 UDP.java > Log: > moved thread starting to handleConnect() from start() (http://jira.jboss.com/jira/browse/JGRP-738) > Revision Changes Path > No revision > No revision > 1.156.2.3 +8 -4 JGroups/src/org/jgroups/protocols/UDP.java > Index: UDP.java > =================================================================== > RCS file: /cvsroot/javagroups/JGroups/src/org/jgroups/protocols/UDP.java,v > retrieving revision 1.156.2.2 > retrieving revision 1.156.2.3 > diff -u -r1.156.2.2 -r1.156.2.3 > --- UDP.java 3 Apr 2008 08:04:19 -0000 1.156.2.2 > +++ UDP.java 23 Apr 2008 09:21:53 -0000 1.156.2.3 > @@ -37,7 +37,7 @@ > * input buffer overflow, consider setting this property to true. > * </ul> > * @author Bela Ban > - * @version $Id: UDP.java,v 1.156.2.2 2008/04/03 08:04:19 belaban Exp $ > + * @version $Id: UDP.java,v 1.156.2.3 2008/04/23 09:21:53 belaban Exp $ > */ > public class UDP extends TP implements Runnable { > @@ -366,7 +366,7 @@ > throw new Exception(tmp, ex); > } > super.start(); > - startThreads(); > + // startThreads(); > } > @@ -377,9 +377,13 @@ > super.stop(); > } > + protected void handleConnect() throws Exception { > + startThreads(); > + } > - > - > + protected void handleDisconnect() { > + stopThreads(); > + } -- 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

18 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-737) Shared transport protocols use stack field from first channel created

by Brian Stansberry (JIRA)

Shared transport protocols use stack field from first channel created --------------------------------------------------------------------- Key: JGRP-737 URL: http://jira.jboss.com/jira/browse/JGRP-737 Project: JGroups Issue Type: Bug Affects Versions: 2.6.2 Reporter: Brian Stansberry Assigned To: Bela Ban Priority: Critical For example, TP.timer is set to TP.stack.timer. TP.stack belongs to an individual channel, not to the set of channels associated with a shared transport. Disconnect the first channel and the others go boom. Did a quick scan of usage of the 'stack' field or the 'getProtocolStack()' method in TP and its subclasses. This usage for the timer is one. Others are: 1) TCP.getConnectionTable calls cTable.setThreadFactory(getProtocolStack().getThreadFactory()); 2) handleDiagnosticProbe uses stack.getChannel() -- 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

18 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-5206) Can't start JBoss 5 with a pure JRE installation

by Javid Jamae (JIRA)

Can't start JBoss 5 with a pure JRE installation ------------------------------------------------- Key: JBAS-5206 URL: http://jira.jboss.com/jira/browse/JBAS-5206 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta3 Environment: Windows XP Reporter: Javid Jamae Can't start JBoss 5 with a pure JRE installation because the startup script looks for a jre/server directory that only exists when you install the JDK (which has a JRE that installs under it). - See forum discussion. -- 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

18 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2023) Modify/Approve of CMS content with activated ApprovePublish workflow fails on Postgres 8.3.1

by Martin Putz (JIRA)

Modify/Approve of CMS content with activated ApprovePublish workflow fails on Postgres 8.3.1 -------------------------------------------------------------------------------------------- Key: JBPORTAL-2023 URL: http://jira.jboss.com/jira/browse/JBPORTAL-2023 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.5 Final, 2.6.4 Final Environment: Fedora Core 9, JBoss EAP 4.3, Postgresql 8.3.1 Reporter: Martin Putz With activated ApprovePublish workflow, hitting the 'Modify/Approve' button after a pending item is in the 'Preview' mode leads to an excpetion: 2008-05-22 13:39:20,559 WARN [org.hibernate.util.JDBCExceptionReporter] SQL Error: 0, SQLState: 22001 2008-05-22 13:39:20,559 ERROR [org.hibernate.util.JDBCExceptionReporter] ERROR: value too long for type character varying(255) This will only show if the content of the previewed file is larger than 255 characters, eg.: 1. open default/index.html 2. make a little modification, hit 'Create' 3. for the newly created item in the 'Pending Approval Queue' hit 'Preview' 4. make another little modification and hit 'Modify/Approve' The SQL insert for JBPM_VARIABLEINSTANCE table fails because the STRINGVALUE_ column is set up with varchar(255). The same works with the out-of-the-box Hypersonic DB. -- 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

18 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2022) Setting org.hibernate.type logging to debug produces no logging

by Martin Putz (JIRA)

Setting org.hibernate.type logging to debug produces no logging --------------------------------------------------------------- Key: JBPORTAL-2022 URL: http://jira.jboss.com/jira/browse/JBPORTAL-2022 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.5 Final Reporter: Martin Putz If you would like to trace the SQL statements Hibernate issues to the Portal tables, you would normally set this in conf/jboss-log4j.xml: <category name="org.hibernate.type"> <priority value="DEBUG"/> </category> <category name="org.hibernate.SQL"> <priority value="DEBUG"/> </category> Due to a Hibernate bug (//opensource.atlassian.com/projects/hibernate/browse/HHH-2835) in combination with a specific mix of logging libraries, this does not produce any 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

18 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4515) Quartz scheduler outputs confusable "XX worker threads active" log when shutdown

by Takayoshi Kimura (JIRA)

Quartz scheduler outputs confusable "XX worker threads active" log when shutdown -------------------------------------------------------------------------------- Key: JBAS-4515 URL: http://jira.jboss.com/jira/browse/JBAS-4515 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-4.2.0.GA Reporter: Takayoshi Kimura Priority: Minor Quartz scheduler always output the following log when shutdown: INFO [org.quartz.simpl.SimpleThreadPool] There are still XX worker threads active. See javadoc runInThread(Runnable) for a possible explanation The thread count XX is not Quartz worker threads. Quarts is using "main" thread group because SimpleThreadPool#isThreadsInheritGroupOfInitializingThread() == true. This is confusing. -- 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

18 years, 2 months

2
1
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 May 2008