October 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-6910) Eliminate use of JGroups IpAddress class in cluster module

by Brian Stansberry (JIRA)

Eliminate use of JGroups IpAddress class in cluster module ---------------------------------------------------------- Key: JBAS-6910 URL: https://jira.jboss.org/jira/browse/JBAS-6910 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 With JGroups 2.8 the type of the address is likely to be different. Biggest source of it is ClusterNodeImpl which takes IpAddress as a constructor param and then returns it as the type of getOriginalJGAddress(). The getOriginalJGAddress() method is not part of the ClusterNode interface and is only used in ClusterPartition, the class which creates the ClusterNodeImpl. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-6295) reference to farm service

by John Davison (JIRA)

reference to farm service ------------------------- Key: JBAS-6295 URL: https://jira.jboss.org/jira/browse/JBAS-6295 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Docs/Clustering Guide Affects Versions: JBossAS-5.0.0.GA, JBossAS-5.0.0.CR2, JBossAS-5.0.0.CR1, JBossAS-5.0.0.Beta4, JBossAS-5.0.0.Beta3 Reporter: John Davison Section 4.3 references the Farming deployment method that is no longer supported in AS 5. It should be modified to reflect as such. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-7250) Upgrade JBoss Cache to 3.2.1.GA

by Brian Stansberry (JIRA)

Upgrade JBoss Cache to 3.2.1.GA ------------------------------- Key: JBAS-7250 URL: https://jira.jboss.org/jira/browse/JBAS-7250 Project: JBoss Application Server Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7118) Update JGroups to 2.6.11

by Brian Stansberry (JIRA)

Update JGroups to 2.6.11 ------------------------ Key: JBAS-7118 URL: https://jira.jboss.org/jira/browse/JBAS-7118 Project: JBoss Application Server Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.2.0.Beta1 Latest bug fix release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
7
0 / 0

[JBoss JIRA] Created: (JBAS-7199) Upgrade JBoss Cache to 3.2.0.GA

by Brian Stansberry (JIRA)

Upgrade JBoss Cache to 3.2.0.GA ------------------------------- Key: JBAS-7199 URL: https://jira.jboss.org/jira/browse/JBAS-7199 Project: JBoss Application Server Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (JGRP-1067) ConnectionTable: eagerly verify TCP connection upon lookup

by Vladimir Blagojevic (JIRA)

ConnectionTable: eagerly verify TCP connection upon lookup ---------------------------------------------------------- Key: JGRP-1067 URL: https://jira.jboss.org/jira/browse/JGRP-1067 Project: JGroups Issue Type: Bug Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 2.8 Whenever node A sends a message to a node B it looks up a connection from a connection table. In cases connection to B is present in A's table - it is returned to a caller, otherwise a new connection is created. However, the above mentioned connection to B might be closed and not yet removed from A's table (think of a case when B closes connection from its end of the pipe). Therefore, the caller who asked for a connection to B might end up with a stale connection that is guaranteed to throw an exception when A attempts to send a message to B. Of course, JGroups will eventually detect that the message is missing and retransmission will kick in but this situation can be remedied by verifying connection status before returning it to a caller. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBAS-7100) Exploding vfsmemory:// contents is empty for web deployments

by Andrew Lee Rubinger (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-7100?page=com.atlassian.jira.plug... ] Andrew Lee Rubinger commented on JBAS-7100: ------------------------------------------- Yes; was planning on doing so after this next big patch I'm working on it complete. If needed sooner ping me and I'll do it in a new workspace. > Exploding vfsmemory:// contents is empty for web deployments > ------------------------------------------------------------ > > Key: JBAS-7100 > URL: https://jira.jboss.org/jira/browse/JBAS-7100 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Reporter: Andrew Lee Rubinger > Assignee: Andrew Lee Rubinger > Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1 > > > The following patch addresses this: > [alrubinger@localhost Branch_5_x]$ svn di server/ > When using an in-memory archive backed by VFS, we're using an "unjar"; this leaves out any RAM-backed resources. Instead explode the contents, regardless of what's behind the virtual abstraction: > Index: server/src/main/org/jboss/web/deployers/AbstractWarDeployer.java > =================================================================== > --- server/src/main/org/jboss/web/deployers/AbstractWarDeployer.java (revision 91204) > +++ server/src/main/org/jboss/web/deployers/AbstractWarDeployer.java (working copy) > -357,7 +357,7 @@ > > VFSDeploymentUnit vfsUnit = (VFSDeploymentUnit)unit; > VirtualFile root = vfsUnit.getRoot(); > - VirtualFile unjared = VFSUtils.unjar(root); > + VirtualFile unjared = VFSUtils.explode(root); > // file was not unjared yet > if (root != unjared) > { > This was exposed by prototyping in EMB-32. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBBUILD-558) Add findbugs and other maven reporting related stuff to the jboss repository

by Paul Gier (JIRA)

Add findbugs and other maven reporting related stuff to the jboss repository ---------------------------------------------------------------------------- Key: JBBUILD-558 URL: https://jira.jboss.org/jira/browse/JBBUILD-558 Project: JBoss Build System Issue Type: Task Reporter: Paul Gier Fix For: Maven Build - Maint 2009 It was requested on the jboss-dev list that the findbugs plugin be added to the jboss maven repository. Other common reporting tools should also be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-902) GossipRouter: raise SUSPECT event when GR detects (abnormal) loss of a connection from client

by Vladimir Blagojevic (JIRA)

GossipRouter: raise SUSPECT event when GR detects (abnormal) loss of a connection from client --------------------------------------------------------------------------------------------- Key: JGRP-902 URL: https://jira.jboss.org/jira/browse/JGRP-902 Project: JGroups Issue Type: Feature Request Affects Versions: 2.7, 2.6 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 2.8 Currently we only support FD-heartbeat based failure detection algorithm for Gossip Router configurations. While this works ok we do not have the same efficiency of failure detection that comes with FD/FD_SOCK combo used in default UDP/TCP configurations. We can bridge that gap by introducing FD_SOCK kind of functionality that is built in GR. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-784) local_addr is null when reconnecting.

by Robert Newson (JIRA)

local_addr is null when reconnecting. ------------------------------------- Key: JGRP-784 URL: http://jira.jboss.com/jira/browse/JGRP-784 Project: JGroups Issue Type: Bug Affects Versions: 2.6.2 Reporter: Robert Newson Assigned To: Bela Ban After shunning, a channel never manages to reconnect (with AUTO_RECONNECT) successfully, reporting this endlessly; org.jgroups.ChannelException: local_addr is null at org.jgroups.JChannel.startStack(JChannel.java:1556) at org.jgroups.JChannel.connect(JChannel.java:364) at org.jgroups.JChannel$CloserThread.run(JChannel.java:1908) 2008-06-10 12:04:31,784 FATAL [CloserThread] jgroups.JChannel (JChannel.java:1555) - local_addr is null; cannot connect 2008-06-10 12:04:31,784 ERROR [CloserThread] jgroups.JChannel$CloserThread (JChannel.java:1912) - failure reconnecting to c hannel, retrying -- 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

14 years, 7 months

5
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2009