July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1020) JBM 1.0 series (SP4 and higher) need to be able to dynamically detect a valid client-side IP interface

by Ovidiu Feodorov (JIRA)

JBM 1.0 series (SP4 and higher) need to be able to dynamically detect a valid client-side IP interface ------------------------------------------------------------------------------------------------------ Key: JBMESSAGING-1020 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1020 Project: JBoss Messaging Issue Type: Patch Components: JMS Remoting Affects Versions: 1.0.1.SP4 Reporter: Ovidiu Feodorov Assigned To: Tim Fox JBM 1.0 series uses a client-side remoting callback server to accept server-to-client TCP connections. This connections are used by the JBM server to asynchronously send messages to the client. However, for multi-homed clients, there are situations when the client sends an incorrect IP address: InetAddress.getLocalHost().getHostAddress() returns a different IP address than one that is visible from the server side. The documentation suggest using "jboss.messaging.callback.bind.address" system property to force an IP address. This approach is not satisfactory, as IP addresses on client machines change upon reboot. The overhead of changing static configuration for each reboot is unacceptable. The problem stems from the fact that InetAddress.getLocalHost(), which is used by the Messaging code as default callback server address, may not be reachable from the JMS server, depending on the routing configuration. The patch uses the assumption that once the direct client-to-server TCP/IP connection is established, the client-side local address of that connection can be reached reached from the server. To get that IP address back to the client, the Remoting protocol should be modified to support a new primitive ("$GET_CLIENT_LOCAL_ADDRESS"), which is only handled by socket transports and ignored by others. The Messaging client sends an invocation containing this primitive immediately after connection is established. If the invocation returns a non-null result, the Messaging client will use that IP address (presumably one of its own local interfaces) to configure the callback server. -- 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, 12 months

1
12
0 / 0

[JBoss JIRA] Updated: (JBCACHE-63) JBossCache benchmarks

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-63?page=all ] Manik Surtani updated JBCACHE-63: --------------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.GA) Complexity: Medium > JBossCache benchmarks > --------------------- > > Key: JBCACHE-63 > URL: http://jira.jboss.com/jira/browse/JBCACHE-63 > Project: JBoss Cache > Issue Type: Task > Affects Versions: 1.2.4SP1 > Reporter: Bela Ban > Assigned To: Phillip Thurmond > Fix For: 2.1.0.GA > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > Also bench against other caches -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-63) JBossCache benchmarks

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-63?page=comments#action_12370525 ] Manik Surtani commented on JBCACHE-63: -------------------------------------- The CacheBenchFwk used here is going to be enhanced in 2 phases: Phase 1. SmartFrog integration to allow for a single command-line script to run the test across 2, 4 and 8 nodes in a cluster, using 3 different configurations (SYNC, ASYNC, BR) and 3 different caching products (JBC1, JBC2, Coherence) Phase 2. Use a load balancer to spread load across the cluster, and measure results on all nodes rather tahn just the coordinator. Phase 1 will make it easier to automate the generation of benchmarks (perhaps even tie it to cruise control builds) and Phase 2 will give us a more accurate abstraction of real-world usage scenarios. > JBossCache benchmarks > --------------------- > > Key: JBCACHE-63 > URL: http://jira.jboss.com/jira/browse/JBCACHE-63 > Project: JBoss Cache > Issue Type: Task > Affects Versions: 1.2.4SP1 > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.0.0.GA > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > Also bench against other caches -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCACHE-63) JBossCache benchmarks

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-63?page=all ] Manik Surtani reassigned JBCACHE-63: ------------------------------------ Assignee: Phillip Thurmond (was: Manik Surtani) > JBossCache benchmarks > --------------------- > > Key: JBCACHE-63 > URL: http://jira.jboss.com/jira/browse/JBCACHE-63 > Project: JBoss Cache > Issue Type: Task > Affects Versions: 1.2.4SP1 > Reporter: Bela Ban > Assigned To: Phillip Thurmond > Fix For: 2.0.0.GA > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > Also bench against other caches -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-508) JBossCache bechmark and performance tuning

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-508?page=all ] Manik Surtani closed JBCACHE-508. --------------------------------- Resolution: Duplicate Issue JBCACHE-63 > JBossCache bechmark and performance tuning > ------------------------------------------ > > Key: JBCACHE-508 > URL: http://jira.jboss.com/jira/browse/JBCACHE-508 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Manik Surtani > Fix For: 2.0.0.GA > > > I have created this task specifically to document our effort in the bechmark and performance tuning process. I am using this tool that I developed to do perf test:http://jira.jboss.com/jira/browse/JBCACHE-503 > Note this load test only emulates the http session pattern now. > I will document the numbers here that I have found and discussed with Bela. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCLUSTER-17) http session replication benchmark and performance tuning

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-17?page=comments#action_12370523 ] Manik Surtani commented on JBCLUSTER-17: ---------------------------------------- See JBCACHE-63 > http session replication benchmark and performance tuning > --------------------------------------------------------- > > Key: JBCLUSTER-17 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-17 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web Tier > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q2Y7 > > > Need to benchmark http session replication using different configurations, e.g., sync mode, granularity, etc. > Also requires JBossCache to do the same first. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-553) JBossCache throughput II

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-553?page=all ] Manik Surtani closed JBCACHE-553. --------------------------------- Resolution: Rejected This test is superceded by the CacheBenchFwk > JBossCache throughput II > ------------------------ > > Key: JBCACHE-553 > URL: http://jira.jboss.com/jira/browse/JBCACHE-553 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Manik Surtani > Fix For: 2.0.0.GA > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Here are the results using the perf test to run our Atl clustering lab. The machines are: 2X 3.0GHZ Xeon, 4GB Ram, GBSwtich, dedicated, 140GB drive. > The load condition are: > 400 clients (total), no sleep, 7kbyte payload > async: > Cluster size, throughtput (req/sec) > 8, 1270 (8.9MB/sec) > 4, 1270 > 2, 1400 > sync: > Cluster size, throughtput (req/sec) > 8, 432 (3.0MB/sec) > 4, 480 > 2, 700 -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-519) Investigate why tx has a higher thruput than non-tx under perf test

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-519?page=all ] Manik Surtani closed JBCACHE-519. --------------------------------- Resolution: Rejected This test is superceded by the CacheBenchFwk > Investigate why tx has a higher thruput than non-tx under perf test > -------------------------------------------------------------------- > > Key: JBCACHE-519 > URL: http://jira.jboss.com/jira/browse/JBCACHE-519 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Manik Surtani > Fix For: 2.0.0.GA > > > During the perf test, I have discovered that the throughput with tx is higher than the non-tx one. This is very puzzling. I have asked Scot Marlow to double check it for me. The same. > Machines are: dev09 and dev17. > Here are some breakdown numbers: > 1. Single thread, 3000 loops, 10 ms sleep interval. > (a) no tx > ----- > Total time spent (ms) per thread: 202921 for 3000 loops > Throughtput for this node with: > threads = 1 > loops = 3000 > sleep interval = 10 > object list size = 100 > tranasaction? false > is: 14 requests/sec > (b) tx > ---- > Total time spent (ms) per thread: 200718 for 3000 loops > Throughtput for this node with: > threads = 1 > loops = 3000 > sleep interval = 10 > object list size = 100 > tranasaction? true > is: 14 requests/sec > 2. 100 threads, 0ms sleep interval > (a) no tx > ----- > Total time spent (ms) per thread: 49352 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 0 > object list size = 100 > tranasaction? false > is: 404 requests/sec > ----- > Total time spent (ms) per thread: 61240 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 20 > object list size = 100 > tranasaction? false > is: 325 requests/sec > -------- dev04 > Total time spent (ms) per thread: 78871 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 20 > object list size = 100 > tranasaction? false > is: 250 requests/sec > (b) tx > ----- > Total time spent (ms) per thread: 68770 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 0 > object list size = 100 > tranasaction? true > is: 288 requests/sec > ---- > Total time spent (ms) per thread: 74575 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 20 > object list size = 100 > tranasaction? true > is: 263 requests/sec > --- dev04 > Total time spent (ms) per thread: 80648 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 20 > object list size = 100 > tranasaction? true > is: 242 requests/sec -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-781) Socket transport needs to provide to the client local address of a TCP/IP connection, as seen from the server

by Ovidiu Feodorov (JIRA)

Socket transport needs to provide to the client local address of a TCP/IP connection, as seen from the server ------------------------------------------------------------------------------------------------------------- Key: JBREM-781 URL: http://jira.jboss.com/jira/browse/JBREM-781 Project: JBoss Remoting Issue Type: Patch Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.0.Alpha7 Reporter: Ovidiu Feodorov This is required by Messaging 1.0 series. See JBMESSAGING-1020 for more details. To get that IP address back to the client, the Remoting protocol should be modified to support a new primitive ("$GET_CLIENT_LOCAL_ADDRESS"), which is only handled by socket transports and ignored by others. A trip to the server is required for NAT-type of situations. -- 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, 12 months

2
4
0 / 0

[JBoss JIRA] Updated: (JBAS-2563) Cleanup the build for jboss5

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2563?page=all ] Scott M Stark updated JBAS-2563: -------------------------------- Priority: Major (was: Critical) > Cleanup the build for jboss5 > ---------------------------- > > Key: JBAS-2563 > URL: http://jira.jboss.com/jira/browse/JBAS-2563 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-5.0.0.Beta3 > > > The current jboss-head build seems rather crusty with outdated modules (media which I removed) and weird modules like jbossas. From the dev list: > This is the remoting/jbossas integration code. > i.e. the UnifiedInvoker > It shouldn't really be in jbossas which was meant to be the top level build folder replacement for "build" > e.g. in the new build > cvs .. co jbossas > cd jbossas > ant rebuild > would pull down all modules and thirdparty and build the release. > Instead jbossas has turned into another "varia" ;-) > On Tue, 2005-12-13 at 03:00, Scott M Stark wrote: > > Why is there this jbossas module in jboss-head when there is also > > remoting being pulled via the thirdparty? > > > We need a plan on cleaning up the jboss-head build using the jbossbuild before creating a jboss5 branch. -- 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, 12 months

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