March 2008 - jboss-remoting-issues

[JBoss JIRA] Closed: (JBREM-923) Assure version compatibility with earlier versions of Remoting

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-923?page=all ] Ron Sigal closed JBREM-923. --------------------------- Resolution: Done Transports http, rmi, and socket pass compatibility tests with versions: 2.2.2.SP5 2.2.2.SP4 2.2.2.SP2 2.2.2.SP1 2.2.2.GA 2.2.1.GA 2.2.0.SP4 2.0.0.GA 1.4.6.GA 1.4.4.GA 1.4.3.GA Transport bisocket passes compatibility tests with versions: 2.2.2.SP5 2.2.2.SP4 2.2.2.SP2 2.2.2.SP1 2.2.2.GA > Assure version compatibility with earlier versions of Remoting > -------------------------------------------------------------- > > Key: JBREM-923 > URL: http://jira.jboss.com/jira/browse/JBREM-923 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.CR1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Critical > Fix For: 2.4.0.CR1 (Pinto) > > > Each version of Remoting must be API and wire compatible with earlier versions, at least as far back as 1.4.3.GA, which is used in JBossAS 4.0.4.GA and 4.0.5.GA. -- 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

16 years, 9 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBREM-923) Assure version compatibility with earlier versions of Remoting

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-923?page=comments#action_12403770 ] Ron Sigal commented on JBREM-923: --------------------------------- The versioning tests for RMI are more elaborate now due to [JBREM-167] - RMI Invoker does not use true remoting marshalling/unmarshalling, which introduced a new wire format. The original wire format may be configured by setting the parameter org.jboss.remoting.transport.rmi.RMIServerInvoker.RMI_ONEWAY_MARSHALLING (actual value "rmiOnewayMarshalling") to "true". The test org.jboss.test.remoting.versioning.transport.rmi.VersionRMIInvokerTestCase has been split into: * org.jboss.test.remoting.versioning.transport.rmi.VersionRMINativeMarshallerTestCase * org.jboss.test.remoting.versioning.transport.rmi.VersionRMIOnewayNativeMarshallerTestCase * org.jboss.test.remoting.versioning.transport.rmi.VersionRMIOnewaySerializableMarshallerTestCase * org.jboss.test.remoting.versioning.transport.rmi.VersionRMISerializableMarshallerTestCase > Assure version compatibility with earlier versions of Remoting > -------------------------------------------------------------- > > Key: JBREM-923 > URL: http://jira.jboss.com/jira/browse/JBREM-923 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.CR1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Critical > Fix For: 2.4.0.CR1 (Pinto) > > > Each version of Remoting must be API and wire compatible with earlier versions, at least as far back as 1.4.3.GA, which is used in JBossAS 4.0.4.GA and 4.0.5.GA. -- 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

16 years, 9 months

1
0
0 / 0

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

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-905?page=all ] Ron Sigal closed JBREM-905. --------------------------- Resolution: Done This release is replaced by 2.2.2.SP5. > 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: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.2.SP4 > Reporter: Jay Howell > Assigned To: Ron Sigal > 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

16 years, 9 months

1
0
0 / 0

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

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-913?page=all ] Ron Sigal closed JBREM-913. --------------------------- Resolution: Done 1. jboss-remoting.jar 2.2.2.SP5-brew is now available: http://repository.jboss.com/jboss/remoting/2.2.2.SP5-brew/ 2. jboss-remoting-2_2_2_SP5.zip is now available: http://labs.jboss.com/downloading/?projectId=jbossremoting&url=http://lab... > 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

16 years, 9 months

1
0
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

16 years, 9 months

1
2
0 / 0

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

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-876?page=all ] Ron Sigal closed JBREM-876. --------------------------- Resolution: Done hudson is sometimes flaky, but it doesn't look like the problems are related to Remoting. > 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.CR1 (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

16 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-920) Create build.xml target to run test suite with a Security Manager

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-920?page=all ] Ron Sigal updated JBREM-920: ---------------------------- Fix Version/s: 2.4.0.GA (was: 2.4.0.CR1 (Pinto)) > Create build.xml target to run test suite with a Security Manager > ----------------------------------------------------------------- > > Key: JBREM-920 > URL: http://jira.jboss.com/jira/browse/JBREM-920 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ron Sigal > Assigned To: David Lloyd > Fix For: 2.4.0.GA > > > From Anil Saldana: > Presuming that you have a test suite and either use ANT or Maven, I > recommend an extra target to run the test suite in a Java Security > Manager with minimal permissions. So for ANT, you will have an > additional target. For MAVEN, you can use a profile. > The idea is that you have a Java Security Policy file in which you > provide unlimited permission to third party libraries and minimal > permissions to your own code. This exercise is to detect critical > sections of code that need special privileges and get into privileged > blocks. If you have an extra target for the security manager and your > test runs happen on hudson, you can detect issues with security manager > as new code gets added. > Please do not have one test that does System.setSecurityManager but run > your entire test suite via the security manager > (-Djava.security.manager -Djava.security.policy=somefile). > Example: (Take a look by clicking "Configure" on the LHS) > http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/ > http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s... > Now if your head is spinning or you do not care about security or do not > have the time to do it, please tell me. I can engage myself, someone > from JBoss Security Team or the QA person handling your project to add a > JIRA issue (and make the build.xml/pom.xml changes for your project). > Why is this important? > * Because many customers run JBAS in a security manager and we need to > detect issues in our own code. Also during a recent integration work > with JBoss Messaging for the SOA platform, there was one issue with > remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is > still reeling). It took some cycles from me also. > * We need to have tests running in a security manager on an ongoing basis. > I understand that there are resource issues in various projects. But > that does not discount the work that we need to do before we ship JBAS. ;) -- 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

16 years, 9 months

1
0
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

16 years, 9 months

1
0
0 / 0

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

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-901?page=all ] Ron Sigal closed JBREM-901. --------------------------- Resolution: Done > 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 > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.CR1 (Pinto) > > > 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

16 years, 9 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

16 years, 9 months

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues March 2008