August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3472) Upgrade jacorb to 2.2.4jboss.patch1

by Dimitris Andreadis (JIRA)

Upgrade jacorb to 2.2.4jboss.patch1 ----------------------------------- Key: JBAS-3472 URL: http://jira.jboss.com/jira/browse/JBAS-3472 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: IIOP service Affects Versions: JBossAS-4.0.4.GA Reporter: Dimitris Andreadis Assigned To: Francisco Reverbel Fix For: JBossAS-4.0.5.CR1, JBossAS-5.0.0.Beta Franscisco, I just noticed you produced jacorb 2.2.4jboss.patch1, so should upgrade Branch_4_0 and HEAD to that? -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Resolved: (JBAS-3242) EE spec requires that web container aborts any active txn at the end of a request

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3242?page=all ] Dimitris Andreadis resolved JBAS-3242. -------------------------------------- Resolution: Done I've changed the config, and will talk to QA to see if we can try measure the impact. > EE spec requires that web container aborts any active txn at the end of a request > --------------------------------------------------------------------------------- > > Key: JBAS-3242 > URL: http://jira.jboss.com/jira/browse/JBAS-3242 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Affects Versions: JBossAS-4.0.4.GA > Reporter: Gavin King > Assigned To: Remy Maucherat > Priority: Critical > Fix For: JBossAS-4.0.5.CR1, JBossAS-5.0.0.Beta > > > The Java EE spec requires that if there is any active JTA transaction at the end of a servlet request, then the container must abort the txn. JBoss currently does not do this. Instead it leaves orphaned transactions dangling about on pooled threads, ready and waiting to be resumed by any random request that comes along. > This is really Bad behavior and I'm kinda shocked. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-488) org.jboss.test.messaging.jms.MessageConsumerTest testRedel1() gets stuck occasionally

by Ovidiu Feodorov (JIRA)

org.jboss.test.messaging.jms.MessageConsumerTest testRedel1() gets stuck occasionally -------------------------------------------------------------------------------------- Key: JBMESSAGING-488 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-488 Project: JBoss Messaging Issue Type: Bug Components: JMS Facade Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Blocker Fix For: 1.0.1.CR4 -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3096) Add a maxInactiveInterval concept to ClusteredSingleSignOn

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3096?page=all ] Brian Stansberry updated JBAS-3096: ----------------------------------- Fix Version/s: JBossAS-5.0.0.Beta Schedule for 5.0.0.Beta as well, in case that goes out before 4.0.6.CR1. > Add a maxInactiveInterval concept to ClusteredSingleSignOn > ---------------------------------------------------------- > > Key: JBAS-3096 > URL: http://jira.jboss.com/jira/browse/JBAS-3096 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service, Security, Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > SSOs are currently invalidated when all sessions associated with the SSO are expired. The problem is webapp undeploy or server shutdown can result in all sessions being expired, even though the sessions are distributed and can thus be accessed on other cluster nodes. If the user then fails over to another server, the SSO is gone. > Not invalidating SSOs when all sessions expire can lead to memory leaks -- SSOs that never can removed from the local and distributed caches. > Idea here is to timestamp the sso when all its sessions are expired, and then some configurable time later invalidate the sso if no new sessions have been added. > Issues: > 1) The TC background thread doesn't call into Valves, so there is no natural thread to check for "expired" SSOs. I'm considering hijacking the regular TC bg thread, since it ends up calling into the valve whenever it expires a session. That's ugly though. > 2) Have to make sure that the other cluster nodes know the sso is "semi-expired" so they can do the expiration check, since often the node where the sso originally lived has been shut down. This should be simple; just another TreeCache event to monitor. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-2950) HAPartition starts successfully even if state transfer fails

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2950?page=comments#action_12340661 ] Brian Stansberry commented on JBAS-2950: ---------------------------------------- I'm working on it; hope to finish it today. > HAPartition starts successfully even if state transfer fails > ------------------------------------------------------------ > > Key: JBAS-2950 > URL: http://jira.jboss.com/jira/browse/JBAS-2950 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Critical > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1 > > > Failure to receive state from the coordinator does not prevent starting a cache. The HAPartitionImpl that's starting just *assumes* it is the coordinator and logs an INFO level message. > We need to determine for sure whether we are the coordinator, and if not, throw an Exception. > We also do nothing to ensure that the setState() call (which is happening in another thread) executes successfully. We need to look at how TreeCache handles this as an example of what to do. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3242) EE spec requires that web container aborts any active txn at the end of a request

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3242?page=all ] Dimitris Andreadis updated JBAS-3242: ------------------------------------- Fix Version/s: JBossAS-4.0.5.CR1 JBossAS-5.0.0.Beta (was: JBossAS-4.0.6.CR1) I will enable it (by default). > EE spec requires that web container aborts any active txn at the end of a request > --------------------------------------------------------------------------------- > > Key: JBAS-3242 > URL: http://jira.jboss.com/jira/browse/JBAS-3242 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Affects Versions: JBossAS-4.0.4.GA > Reporter: Gavin King > Assigned To: Remy Maucherat > Priority: Critical > Fix For: JBossAS-4.0.5.CR1, JBossAS-5.0.0.Beta > > > The Java EE spec requires that if there is any active JTA transaction at the end of a servlet request, then the container must abort the txn. JBoss currently does not do this. Instead it leaves orphaned transactions dangling about on pooled threads, ready and waiting to be resumed by any random request that comes along. > This is really Bad behavior and I'm kinda shocked. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-3306) Upgrade JBoss AS to use MyFaces 1.1.3

by Stan Silvert (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3306?page=comments#action_12340660 ] Stan Silvert commented on JBAS-3306: ------------------------------------ They are testing a release candidate now. Judging from the dev mailing list, I'd say that there is enough activity to get the release done this weekend. Of course we can use any snapshot and I'm confident that it would mostly work. But I'd rather ship a blessed version that has passed TCK and doesn't contain any major known bugs. The MyFaces team has screwed up the last couple of releases and they are trying to be more careful this time. > Upgrade JBoss AS to use MyFaces 1.1.3 > ------------------------------------- > > Key: JBAS-3306 > URL: http://jira.jboss.com/jira/browse/JBAS-3306 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: JBossAS-4.0.4.GA > Reporter: Gavin King > Assigned To: Stan Silvert > Priority: Critical > Fix For: JBossAS-4.0.5.CR1 > > > We need to upgrade JBoss to use MyFaces 1.1.3, which fixes many bugs. This is critical priority for Seam. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (SWAP-13) Stop using download module, and create static html pages.

by Roy Russo (JIRA)

[ http://jira.jboss.com/jira/browse/SWAP-13?page=all ] Roy Russo resolved SWAP-13. --------------------------- Fix Version/s: PortletSwap 2.0 Resolution: Done > Stop using download module, and create static html pages. > --------------------------------------------------------- > > Key: SWAP-13 > URL: http://jira.jboss.com/jira/browse/SWAP-13 > Project: PortletSwap > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Infrastructure > Affects Versions: PortletSwap 2.0 > Reporter: Roy Russo > Assigned To: Roy Russo > Fix For: PortletSwap 2.0 > > > Need download links to .war, .zip (whole project), and a link to the svn home for src browsing - for every portlet. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-3306) Upgrade JBoss AS to use MyFaces 1.1.3

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3306?page=comments#action_12340653 ] Dimitris Andreadis commented on JBAS-3306: ------------------------------------------ It seems there is a Version 1.1.4-SNAPSHOT version. Should we try this one? > Upgrade JBoss AS to use MyFaces 1.1.3 > ------------------------------------- > > Key: JBAS-3306 > URL: http://jira.jboss.com/jira/browse/JBAS-3306 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: JBossAS-4.0.4.GA > Reporter: Gavin King > Assigned To: Stan Silvert > Priority: Critical > Fix For: JBossAS-4.0.5.CR1 > > > We need to upgrade JBoss to use MyFaces 1.1.3, which fixes many bugs. This is critical priority for Seam. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-2950) HAPartition starts successfully even if state transfer fails

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2950?page=comments#action_12340652 ] Dimitris Andreadis commented on JBAS-2950: ------------------------------------------ Brian, any chance on working on this until Monday? > HAPartition starts successfully even if state transfer fails > ------------------------------------------------------------ > > Key: JBAS-2950 > URL: http://jira.jboss.com/jira/browse/JBAS-2950 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Critical > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1 > > > Failure to receive state from the coordinator does not prevent starting a cache. The HAPartitionImpl that's starting just *assumes* it is the coordinator and logs an INFO level message. > We need to determine for sure whether we are the coordinator, and if not, throw an Exception. > We also do nothing to ensure that the setState() call (which is happening in another thread) executes successfully. We need to look at how TreeCache handles this as an example of what to do. -- 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, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2006