March 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-905) Client side connection exception is not thrown on the client side when the lease times out

by Jay Howell (JIRA)

Client side connection exception is not thrown on the client side when the lease times out ------------------------------------------------------------------------------------------ Key: JBREM-905 URL: http://jira.jboss.com/jira/browse/JBREM-905 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP4 Reporter: Jay Howell Fix For: 2.2.2.SP4_CP01 Migrate change into the CP from 2.2.2sp5 - Client side connection exception is not thrown on the client side when the lease times out -- 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, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-913) Release 2.2.2.SP5

by Ron Sigal (JIRA)

Release 2.2.2.SP5 ----------------- Key: JBREM-913 URL: http://jira.jboss.com/jira/browse/JBREM-913 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP5 -- 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, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-931) Create and run soak test

by Ron Sigal (JIRA)

Create and run soak test ------------------------ Key: JBREM-931 URL: http://jira.jboss.com/jira/browse/JBREM-931 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.CR1 (Pinto) Need to run some long term tests to look for leakage, other problems. -- 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, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1207) Move ClientContainer/ClientLauncher out of ejb3 core into jbossas

by Scott M Stark (JIRA)

Move ClientContainer/ClientLauncher out of ejb3 core into jbossas ----------------------------------------------------------------- Key: EJBTHREE-1207 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1207 Project: EJB 3.0 Issue Type: Task Affects Versions: AS 5.0.0.Beta4 Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: AS 5.0.0.CR1 Move the org.jboss.ejb3.client.* classes for the application client launcher into jbossas/ejb3 project. -- 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, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-876) Get Remoting testsuite to run in hudson

by Ron Sigal (JIRA)

Get Remoting testsuite to run in hudson --------------------------------------- Key: JBREM-876 URL: http://jira.jboss.com/jira/browse/JBREM-876 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) The jrunit based Remoting tests are failing in hudson. The problem might be that jrunit depends on multicasting in jgroups. Aleksandar Kostadinov has said: 1. Let me know if it is related to multicast listener on lo and a multicast sender. There is a change in behavior after RHEL 4.4 in that regard and I suspect that is the reason tests to pass on the old build hosts and not on the new hudson ones. 2. How can we make it not bind to localhost? I don't think it will be possible to have these passing without that. Will -Dbind_addr=something and -Dlocal_addr=something change that or this has to be done in some property files as well? -- 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, 4 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-901) can't start NetworkRegistry if hostname is not resolvable

by John Mazzitelli (JIRA)

can't start NetworkRegistry if hostname is not resolvable --------------------------------------------------------- Key: JBREM-901 URL: http://jira.jboss.com/jira/browse/JBREM-901 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.1.GA Reporter: John Mazzitelli Priority: Minor Suppose I have a box whose hostname is not resolvable via DNS (I know, I know, but for people demo'ing software on a laptop, we've seen it happen). So, I cannot "ping `hostname`" but I can "ping 127.0.0.1". Look at NetworkRegistry: public ObjectName preRegister(MBeanServer mBeanServer, ObjectName objectName) throws Exception { this.mBeanServer = mBeanServer; this.objectName = objectName; // make sure our identity system property is properly set Identity identity = Identity.get(this.mBeanServer); ... Now look at the Identity.get() method it called there: if(identities.containsKey(server)) { return (Identity) identities.get(server); } try { String serverid = (String) server.getAttribute(new ObjectName("JMImplementation:type=MBeanServerDelegate"), "MBeanServerId"); Identity identity = new Identity(InetAddress.getLocalHost(), createId(server), serverid); identities.put(server, identity); return identity; } It calls InetAddress.getLocalHost() but if that fails (and it will if the local hostname is not resolvable) you can *never* start a NetworkRegistry object. If there is an exception here in that call to InetAddress.getLocalHost(), it should fallback and use: InetAddress getByName("127.0.0.1"). I tried setting "jboss.identity" sysprop to Identity.createUniqueID() but unfortunately, that sysprop isn't used in this class and NetworkRegistry never looks to see if that is set as a fallback. I understand that without a resolvable host, it hobbles things - but for demo purposes of software that will ONLY ever run on a single laptop over the loopback network adapter on 127.0.0.1, this should still work without me having to disable things like the NetworkRegistry. -- 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, 4 months

2
4
0 / 0

[JBoss JIRA] Updated: (JBREM-373) clean up lease handling on server side

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-373?page=all ] Ron Sigal updated JBREM-373: ---------------------------- Fix Version/s: 2.4.0.GA (was: 2.4.0.CR1 (Pinto)) > clean up lease handling on server side > -------------------------------------- > > Key: JBREM-373 > URL: http://jira.jboss.com/jira/browse/JBREM-373 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.0.0.Beta1 > Reporter: Tom Elrod > Priority: Minor > Fix For: 2.4.0.GA > > > In issue JBREM-372, put in a hack for cleaning up lease map within the ServerInvoker where would pass the clientLeases variable from ServerInvoker to the constructor of Lease. Then when LeaseTimerTask fired and event that client was dead, would remove itself from the ServerInvoker's lease map (by client id). > Should not have to pass in the lease map from ServerInvoker. Maybe better approach would be to have ServerInvoker add itself as listener, so when the connection failure event fired, it would be notified and remove the lease from the clientLeases map itself. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-933) Fix memory leak in RemotingRMIClientSocketFactory

by Ron Sigal (JIRA)

Fix memory leak in RemotingRMIClientSocketFactory ------------------------------------------------- Key: JBREM-933 URL: http://jira.jboss.com/jira/browse/JBREM-933 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta2 (Pinto) Reporter: Ron Sigal Fix For: 2.4.0.CR1 (Pinto) org.jboss.remoting.transport.rmi.RMIClientInvoker.handleConnect() stores the configuration map for later use by the RemotingRMIClientSocketFactory. RMIClientInvoker.handleDisconnect() should remove the configuration map. -- 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, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-5323) Set loopback="true" in all JGroups stacks

by Brian Stansberry (JIRA)

Set loopback="true" in all JGroups stacks ----------------------------------------- Key: JBAS-5323 URL: http://jira.jboss.com/jira/browse/JBAS-5323 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 FLUSH and MuxChannel service view messages need to be received by the sender. If there is a problem with multicast on the interface the channel is using, the messages will not be received, leading to long delays and incorrect behavior. Per Bela, it is fine (desirable) to set loopback="true" in the transport protocol in each stack. This will ensure the channel receives its own messages. If multicast isn't working, the channel will of course not be able to communicate with other members, and thus isn't really working properly. But, debugging and resolving these sorts of connectivity issues is something well documented in JGroups docs, wikis etc. The new weird behavior you get when FLUSH and MuxChannel can't receive their own messages is not easy to understand. -- 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, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1893) Improve ContainerCapabiltiesInfo

by Julien Viet (JIRA)

Improve ContainerCapabiltiesInfo -------------------------------- Key: JBPORTAL-1893 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1893 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Portlet Affects Versions: Portlet-2.0 Reporter: Julien Viet Assigned To: Julien Viet Fix For: Portlet-2.0 take in account: - optimization in getSupportedModes(String mimeType) to cache stuff (actually pre compute) - make getSupportWindowStates(String mimeType) work the same way getSupportedModes since now portlet 2 spec allows to define supported window states within a <supports> section -- 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, 4 months

1
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 March 2008