November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBUILD-366) Mavenize Mobicents

by Paul Gier (JIRA)

Mavenize Mobicents ------------------ Key: JBBUILD-366 URL: http://jira.jboss.com/jira/browse/JBBUILD-366 Project: JBoss Build System Issue Type: Feature Request Components: Maven Reporter: Paul Gier Mavenize Mobicents -- 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: (JBMICROCONT-215) The types need removing from the deployment[context|unit] api

by Adrian Brock (JIRA)

The types need removing from the deployment[context|unit] api ------------------------------------------------------------- Key: JBMICROCONT-215 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-215 Project: JBoss MicroContainer Issue Type: Task Components: Deployment Affects Versions: JBossMC-2.0.0.Beta6 Reporter: Adrian Brock The "types" need removing from the deployment api. This information is intended for the profile service/console so it can categorize "ManagedObject"s. As such, it more correctly belongs on that api. This confusion has become important since it is being miused for different purposes see JBAS-4940 -- 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
8
0 / 0

[JBoss JIRA] Created: (SECURITY-32) White Paper on Clustered SSO

by Anil Saldhana (JIRA)

White Paper on Clustered SSO ---------------------------- Key: SECURITY-32 URL: http://jira.jboss.com/jira/browse/SECURITY-32 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: White Papers Affects Versions: 2.0 Reporter: Anil Saldhana Assigned To: Sakthi Samabsivam Fix For: 2.0 White paper on the Clustered SSO offering from JBoss. http://wiki.jboss.org/wiki/Wiki.jsp?page=SingleSignOn http://wiki.jboss.org/wiki/Wiki.jsp?page=BuddyReplicationAndClusteredSSO This is important because many customers are using this along with http session replication. -- 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
12
0 / 0

[JBoss JIRA] Created: (JBAS-4431) Allow FK index creation during startup (CMP2)

by Jesper Pedersen (JIRA)

Allow FK index creation during startup (CMP2) --------------------------------------------- Key: JBAS-4431 URL: http://jira.jboss.com/jira/browse/JBAS-4431 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: CMP service Affects Versions: JBossAS-4.2.0.GA Environment: Branch_4_2 and JDK5 Reporter: Jesper Pedersen Assigned To: Alexey Loubyansky Currently indexes for FK columns are only created when the table is created. An enhancement is to create indexes during startup if an index doesn't exists for the FK column and it is specified in jbosscmp-jdbc.xml. The following patch implements this functionality. The patch has passed internal testing as well as the AS testsuite. The work was sponsored by World League Sports and licensed under LGPL. -- 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
9
0 / 0

[JBoss JIRA] Created: (JBWEB-82) JBossWeb leaves hung ajp connections with mod_jk

by Devon Hillard (JIRA)

JBossWeb leaves hung ajp connections with mod_jk ------------------------------------------------ Key: JBWEB-82 URL: http://jira.jboss.com/jira/browse/JBWEB-82 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Tomcat Module Environment: Apache 2.2.3, mod_jk 1.2, JBoss 4.2.0.GA Reporter: Devon Hillard Assigned To: Mladen Turk I have a Debian (stable) server which is running Apache 2.2.3, and using mod_jk to connect to my application running within JBoss. I have been running with this using JBoss 4.0.5 for many months, without issue. I just upgraded to JBoss 4.2.0. Things start off fine, however after running for a while (last night it took 6.5 hours) the mod_jk logs start showing these errors: Code: [Wed Jun 06 07:45:00 2007][29336:14016] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (948 ): (node1) can't receive the response message from tomcat, network problems or tomcat is down (*MyIP *:8009), err=-104 [Wed Jun 06 07:45:00 2007][29336:14016] [error] ajp_get_reply::jk_ajp_common.c (1566): (node1) Tomca t is down or refused connection. No response has been sent to the client (yet) [Wed Jun 06 07:45:00 2007][29336:14016] [error] ajp_service::jk_ajp_common.c (1928): (node1) Connect ing to tomcat failed. Tomcat is probably not started or is listening on the wrong port These errors do NOT happen with each request. They happen perhaps one out of five, although it seems to fluctuate. Most requests work, but many don't. There are NO errors in the JBoss logs. I have tried using 127.0.0.1 and my actual non-loopback IP address and the same thing happens. I can fix it by restarting JBoss, then everything works, for a few hours at least, before the problem starts up again. ----------------- More information: This appears to be related to open connections. mod_jk was holding connections open to the JBoss web server on 8009, and the number of ESTABLISHED connections kept growing until tomcat started rejecting new connections. Some of the connections would get reused, but not that many. I set the connection_pool_timeout in the mod_jk config to 10 seconds. This keeps the number of established connections down around 50-60. However, the connections that have timed out of the pool, appear to persist forever. The connection from the mod_jk TO JBossWeb sticks in FIN_WAIT1 or FIN_WAIT2: 10.10.77.194:57587 10.10.77.194:8009 FIN_WAIT1 The connection view from JBossWeb gets stuck in CLOSE_WAIT: 10.10.77.194:8009 10.10.77.194:57587 CLOSE_WAIT Once the number of connections hits 1024 (or thereabouts) everything falls apart, of course, and I have to kill -9 jboss and start it up again. This never happened with JBoss 4.0.5. Apache and mod_jk haven't changed at all, so this has to be a change between Tomcat 5.5 or JBossWeb. I can't be the only person to run into this..... -- 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

6
10
0 / 0

[JBoss JIRA] Created: (JBAOP-479) Enable org.jboss.test.aop.proxy.ProxyTestCase(jdk14).testAnnotationsExistInProxy

by Kabir Khan (JIRA)

Enable org.jboss.test.aop.proxy.ProxyTestCase(jdk14).testAnnotationsExistInProxy -------------------------------------------------------------------------------- Key: JBAOP-479 URL: http://jira.jboss.com/jira/browse/JBAOP-479 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.GA public void testAnnotationsExistInProxy() throws Exception { //THis test fails if we run with jboss retro try { Class.forName("org.jboss.lang.ClassRedirects"); System.out.println("IGNORING TEST ON JDK 1.4"); return; } catch(Exception ignoreWeAreRunningWithJDK5) { } This *might* be deferrable to a later release since it is a JDK 1.4 thing and AOP 2.0 is targeting AS 5 (JDK 5) -- 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: (HIBERNATE-70) Interceptor.onLoad not called from EJB3 event listeners

by Wise Guy (JIRA)

Interceptor.onLoad not called from EJB3 event listeners ------------------------------------------------------- Key: HIBERNATE-70 URL: http://jira.jboss.com/jira/browse/HIBERNATE-70 Project: Hibernate Issue Type: Bug Environment: JBoss 4.2.1.GA, Hibernate 3.2.1 SP1, Seam 1.2.1.GA Reporter: Wise Guy Assigned To: Steve Ebersole Priority: Minor I have a Seam 1.2.1.GA application. I installed an implementation of the interface org.hibernate.Interceptor and declared it in the persistence.xml as hibernate.ejb.interceptor. The interceptor works (ex.: onSave(), onFlushDirty()) except that onLoad() doesn't get called. I guess that there is a problem with the DefaultPreLoadEventListener who should call my interceptor. He is defined in org.hibernate.event.EventListeners as a default listener to the event "pre-load". I also found that the DefaultLoadEventListener.onLoad() gets called but DefaultPreLoadEventListener.onPreLoad() not. Does that have something to do with EJB3? I have found that there is an EJB3PostLoadEventListener that is used when run under JPA and the default listeners are overridden. -- 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

[JBoss JIRA] Created: (EJBTHREE-1136) Upon restart a failed node sees stale persisted SFSBs

by Brian Stansberry (JIRA)

Upon restart a failed node sees stale persisted SFSBs ----------------------------------------------------- Key: EJBTHREE-1136 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1136 Project: EJB 3.0 Issue Type: Bug Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: AS 4.2.3.GA, HEAD StatefulTreeCache needs to always purge all state in its region (including passivated sessions stored by the cache loader) as part of initialize processing. It purges as part of stop() but that's inadequate, as stop() isn't called when a node crashes. Effect here is if buddy replication is used and a crashed node is restarted, the buddy group tree state transfer doesn't override the old persistent state in the main tree. If a failover request then comes in for a session previously persisted in the main tree, instead of gravitating the data from the current owner the stale data is read from disk. -- 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: (JBRULES-1258) serialising a package breaks function removal

by Mark Proctor (JIRA)

serialising a package breaks function removal ---------------------------------------------- Key: JBRULES-1258 URL: http://jira.jboss.com/jira/browse/JBRULES-1258 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.1 Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: FUTURE DynamicRulesTest.testDynamicFunction breaks if you serialise the package first before use. On inspection I cannot initially see what is going wrong. The code seems to be successfully recreating the new classloader and re-writing all invokers, yet it still fails :( -- 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
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1095) Deserializing Package Objects Consumes Large Amount of Memory

by Ming Jin (JIRA)

Deserializing Package Objects Consumes Large Amount of Memory ------------------------------------------------------------- Key: JBRULES-1095 URL: http://jira.jboss.com/jira/browse/JBRULES-1095 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.GA Environment: Windows Reporter: Ming Jin Assigned To: Mark Proctor Deserializing the Package objects from storage to memory consumes large amount of memory. My tests showed that for a serialized size of 1MB, 18MB of memory would be consumed during deserialization, mostly from the method org.drools.rule.Package.readExternal. A test program with resulting profile data would be uploaded. -- 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

3
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 November 2007