August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBCLUSTER-113) WSAS Http Session replication using JBossCache

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-113?page=all ] Brian Stansberry updated JBCLUSTER-113: --------------------------------------- Fix Version/s: Q2Y7 > WSAS Http Session replication using JBossCache > ---------------------------------------------- > > Key: JBCLUSTER-113 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-113 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Fix For: Q2Y7 > > > Similar to JBCLUSTER--112, but for Websphere. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-119) Effect of different JGroups transports

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-119?page=all ] Brian Stansberry updated JBCLUSTER-119: --------------------------------------- Attachment: ResultsExtract.pdf Attached an extract of my presentation from JavaOne. > Effect of different JGroups transports > -------------------------------------- > > Key: JBCLUSTER-119 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-119 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: Q3Y6 > > Attachments: ResultsExtract.pdf, tc5-cluster-service.xml.nio, tc5-cluster-service.xml.tcp, tc5-cluster-service.xml.udp > > > Need to see in which cluster topologies UDP, TCP and TCP_NIO perform best. Particularly, how big of a cluster before UDP pays off. Need to factor buddy replication into this. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-126) Lookup fails during failover

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-126?page=all ] Brian Stansberry updated JBCLUSTER-126: --------------------------------------- Fix Version/s: Bugs > Lookup fails during failover > ---------------------------- > > Key: JBCLUSTER-126 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-126 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: jboss 3.2.6 > OS: SUSE LINUX 10 > Reporter: Sangeetha Pisharody > Assigned To: Brian Stansberry > Fix For: Bugs > > > I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup > Properties p = System.getProperties(); > p.put(Context.PROVIDER_URL, "localhost:1100"); > Context jndiContext = new InitialContext(p); > jndiContext.lookup("XAConnectionFactory"); > I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw > javax.naming.NameNotFoundException: XAConnectionFactory > at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237) > at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201) > at $Proxy42.lookup(Unknown Source) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583) > at javax.naming.InitialContext.lookup(InitialContext.java:347) > at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133) > at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:96) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484) > at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207) > at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144) > at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197) > at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133) > at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211) > at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780) > at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236) > at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554) > at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691) > at java.lang.Thread.run(Thread.java:534) > This happened on our test cluster. > On the production cluster, we saw a similar issue when because of a brief network issue the master failed over. > Services that lookup XAConnectionFactory threw a similar exception. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCLUSTER-100) AS4.0.4CR2 and AS4.0.3SP1 benchmark comparison

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-100?page=all ] Brian Stansberry resolved JBCLUSTER-100. ---------------------------------------- Fix Version/s: Q2Y6 Resolution: Done > AS4.0.4CR2 and AS4.0.3SP1 benchmark comparison > ---------------------------------------------- > > Key: JBCLUSTER-100 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-100 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q2Y6 > > Attachments: 4.0.4vs4.0.3.xls, tc5-sync.xml, tc5.xml > > > Used jbento2 with ComplexMap model of 16 (3k) and 64 (12k) to compare the performance between 4.0.3 and 4.0.4. JGroups used is 2.2.9.1 and JBossCache 1.2.4SP2. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCLUSTER-100) AS4.0.4CR2 and AS4.0.3SP1 benchmark comparison

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-100?page=all ] Brian Stansberry reassigned JBCLUSTER-100: ------------------------------------------ Assignee: Brian Stansberry (was: Ben Wang) > AS4.0.4CR2 and AS4.0.3SP1 benchmark comparison > ---------------------------------------------- > > Key: JBCLUSTER-100 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-100 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q2Y6 > > Attachments: 4.0.4vs4.0.3.xls, tc5-sync.xml, tc5.xml > > > Used jbento2 with ComplexMap model of 16 (3k) and 64 (12k) to compare the performance between 4.0.3 and 4.0.4. JGroups used is 2.2.9.1 and JBossCache 1.2.4SP2. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-100) AS4.0.4CR2 and AS4.0.3SP1 benchmark comparison

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-100?page=all ] Brian Stansberry updated JBCLUSTER-100: --------------------------------------- Attachment: 4.0.4vs4.0.3.xls Attached is the comparison I performed in March. > AS4.0.4CR2 and AS4.0.3SP1 benchmark comparison > ---------------------------------------------- > > Key: JBCLUSTER-100 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-100 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q2Y6 > > Attachments: 4.0.4vs4.0.3.xls, tc5-sync.xml, tc5.xml > > > Used jbento2 with ComplexMap model of 16 (3k) and 64 (12k) to compare the performance between 4.0.3 and 4.0.4. JGroups used is 2.2.9.1 and JBossCache 1.2.4SP2. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-99) 4.0.4CR2 under Jbento load test numbers

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-99?page=all ] Brian Stansberry updated JBCLUSTER-99: -------------------------------------- Attachment: ResultsExtract.pdf Attached is an extract from the presentation Takayuki and I did at JavaOne. Conversion to PDF made the slide headings look odd. > 4.0.4CR2 under Jbento load test numbers > --------------------------------------- > > Key: JBCLUSTER-99 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-99 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: Q2Y6 > > Attachments: ResultsExtract.pdf > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > I have used JBento to perform load test with 2 nodes cluster (dev02, dev03). It only loads dev02 (so not load balanced yet). This is just a simple counter String test. > 1. 10 clients with 10 ms sleep in between. The tps is 85. No error message produced > 2. 50 client with 10ms sleep. Lots of errors: > 2006-03-20 16:05:18,667 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3277 not > found in sent_msgs ! sent_msgs=[1477 - 3502] > 2006-03-20 16:05:18,668 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3278 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > 2006-03-20 16:05:18,668 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3279 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > 2006-03-20 16:05:18,669 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3280 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > The other node also ran into OOM 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCLUSTER-99) 4.0.4CR2 under Jbento load test numbers

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-99?page=all ] Brian Stansberry reassigned JBCLUSTER-99: ----------------------------------------- Assignee: Brian Stansberry (was: Ben Wang) > 4.0.4CR2 under Jbento load test numbers > --------------------------------------- > > Key: JBCLUSTER-99 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-99 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q2Y6 > > Attachments: ResultsExtract.pdf > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > I have used JBento to perform load test with 2 nodes cluster (dev02, dev03). It only loads dev02 (so not load balanced yet). This is just a simple counter String test. > 1. 10 clients with 10 ms sleep in between. The tps is 85. No error message produced > 2. 50 client with 10ms sleep. Lots of errors: > 2006-03-20 16:05:18,667 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3277 not > found in sent_msgs ! sent_msgs=[1477 - 3502] > 2006-03-20 16:05:18,668 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3278 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > 2006-03-20 16:05:18,668 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3279 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > 2006-03-20 16:05:18,669 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3280 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > The other node also ran into OOM 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCLUSTER-99) 4.0.4CR2 under Jbento load test numbers

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-99?page=all ] Brian Stansberry resolved JBCLUSTER-99. --------------------------------------- Fix Version/s: Q2Y6 Resolution: Done > 4.0.4CR2 under Jbento load test numbers > --------------------------------------- > > Key: JBCLUSTER-99 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-99 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q2Y6 > > Attachments: ResultsExtract.pdf > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > I have used JBento to perform load test with 2 nodes cluster (dev02, dev03). It only loads dev02 (so not load balanced yet). This is just a simple counter String test. > 1. 10 clients with 10 ms sleep in between. The tps is 85. No error message produced > 2. 50 client with 10ms sleep. Lots of errors: > 2006-03-20 16:05:18,667 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3277 not > found in sent_msgs ! sent_msgs=[1477 - 3502] > 2006-03-20 16:05:18,668 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3278 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > 2006-03-20 16:05:18,668 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3279 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > 2006-03-20 16:05:18,669 ERROR [org.jgroups.protocols.pbcast.NAKACK] (requester=1 > 72.16.130.57:41887, local_addr=172.16.129.57:49802) message with seqno=3280 not > found in sent_msgs ! sent_msgs=[1477 - 3503] > The other node also ran into OOM 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCLUSTER-72) Certify JBoss Clustering Content on JBoss Labs

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-72?page=all ] Brian Stansberry reassigned JBCLUSTER-72: ----------------------------------------- Assignee: Brian Stansberry (was: Ben Wang) > Certify JBoss Clustering Content on JBoss Labs > ---------------------------------------------- > > Key: JBCLUSTER-72 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-72 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Damon Sicore > Assigned To: Brian Stansberry > Fix For: Q3Y6 > > > See incorporated task for instructions. -- 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

19 years, 11 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 August 2006