September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBAS-2272) Clustering unit test failures - TCP stack

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2272?page=all ] Brian Stansberry closed JBAS-2272. ---------------------------------- Resolution: Done > Clustering unit test failures - TCP stack > ----------------------------------------- > > Key: JBAS-2272 > URL: http://jira.jboss.com/jira/browse/JBAS-2272 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: JBossAS-4.0.5.GA > > > Resolve why we get numerous test case failures when using the tcp stack, even if as much as 2 seconds are allowed for state propagation across the cluster. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3711) Update to JGroups 2.2.7.SP1

by Brian Stansberry (JIRA)

Update to JGroups 2.2.7.SP1 --------------------------- Key: JBAS-3711 URL: http://jira.jboss.com/jira/browse/JBAS-3711 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-4.0.5.GA JGroups will release a 2.2.7.SP1 in the next day or so. This will provide the ability to set TCP_NO_DELAY on TCP sockets. Integrate this so 4.0.5.GA can have reduced RPC call latency when using a TCP config. -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3712) Use TCP_NO_DELAY on sockets if HAPartition uses TCP

by Brian Stansberry (JIRA)

Use TCP_NO_DELAY on sockets if HAPartition uses TCP --------------------------------------------------- Key: JBAS-3712 URL: http://jira.jboss.com/jira/browse/JBAS-3712 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-4.0.5.GA HAPartition makes synchronous RPC calls; to improve latency we should disabling nagling by setting the new JGroups TCP.tcp_nodelay flag to true. -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1059) Fix Theme module tests

by Roy Russo (JIRA)

Fix Theme module tests ---------------------- Key: JBPORTAL-1059 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1059 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Theme Affects Versions: 2.6.Alpha1 Reporter: Roy Russo Assigned To: Roy Russo Fix For: 2.6.Alpha1 Changes in the testsuite runner, have made the theme api tests not deploy/run. -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBAS-2470) Test multiple partitions and subsequent merges using Gossip Router

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2470?page=all ] Brian Stansberry updated JBAS-2470: ----------------------------------- Fix Version/s: JBossAS-5.0.1.CR1 > Test multiple partitions and subsequent merges using Gossip Router > ------------------------------------------------------------------ > > Key: JBAS-2470 > URL: http://jira.jboss.com/jira/browse/JBAS-2470 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: JBossAS-5.0.1.CR1 > > > Create tests of the merge handling of HAPartition and related classes by using a GossipRouter in the JGroups config. A split in the partition can be simulated by killing the GR, merge > can be triggered by restarting it. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3138) HAJNDI lookup fails intermittently from twiddle

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3138?page=all ] Brian Stansberry updated JBAS-3138: ----------------------------------- Fix Version/s: No Release Fix version "No Release" means "not sure when, but not soon." > HAJNDI lookup fails intermittently from twiddle > ----------------------------------------------- > > Key: JBAS-3138 > URL: http://jira.jboss.com/jira/browse/JBAS-3138 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering, JMX, Naming > Affects Versions: JBossAS-5.0.0.Beta, JBossAS-4.0.4.CR2 > Environment: This bug is present in JBoss 3.2.6 and 4.0.3. To produce setup a two node cluster, such as in the lab-clustering. This bug is reproducable on Windows XP, Linux WS3, & Solaris 10. > Reporter: Brian Stansberry > Priority: Minor > Fix For: No Release > > > Brian Egge reported in JBCLUSTER-83: > Running twiddle against the HAJNDI port will sometimes fail, and sometimes work. It does not matter if you query the server which has the component, or the failover server. Both produce the same result. Using the standard JDNI port always works, if you query the correct server. Using the HAJNDI fails ~50% of the time: > C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1200 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName > ReceiversCount=0 > QueueName=A > C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1200 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName > ReceiversCount=0 > QueueName=A > C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1200 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName > 12:26:40,320 ERROR [Twiddle] Exec failed > javax.management.InstanceNotFoundException: jboss.mq.destination:name=A,service=Queue is not registered. > at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:508) > at org.jboss.mx.server.MBeanServerImpl.getAttributes(MBeanServerImpl.java:547) > at sun.reflect.GeneratedMethodAccessor83.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:251) > at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) > at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:74) > at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:74) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) > at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:164) > at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) > at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805) > at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406) > at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) > at sun.rmi.transport.Transport$1.run(Transport.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:149) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) > at java.lang.Thread.run(Thread.java:595) > The JNDI port always works: > C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1199 get jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName > ReceiversCount=0 > QueueName=A > C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1199 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName > ReceiversCount=0 > QueueName=A > * In these examples, clust2 is running using the bind config port-01, which adds 100 to the ports. The bug is the same when on a single machine or multiple. The above examples are the same when using 1099/1100. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2440) Review use of HashMap vs. Map as a type declaration in DistributedReplicantManagerImpl

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2440?page=all ] Brian Stansberry updated JBAS-2440: ----------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 > Review use of HashMap vs. Map as a type declaration in DistributedReplicantManagerImpl > -------------------------------------------------------------------------------------- > > Key: JBAS-2440 > URL: http://jira.jboss.com/jira/browse/JBAS-2440 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Assigned To: Jerry Gauthier > Fix For: JBossAS-5.0.0.CR1 > > > There are a lot of places in DistributedReplicantManagerImpl where variables are declared as HashMap instead of Map. Since a number of internal members have been changed to ConcurrentReaderHashMap, this is dangerous (see JBAS-2439). Need to review and where possible use Map instead of HashMap. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-3257) HANamingService: Enable definition of RmiBindAddress analogous to RmiBindPort

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3257?page=comments#action_12344163 ] Brian Stansberry commented on JBAS-3257: ---------------------------------------- Jerry, can you assign a Fix Version to this? If the answer is "no time in the next 9 months", please set Fix Version to "No Release". > HANamingService: Enable definition of RmiBindAddress analogous to RmiBindPort > ----------------------------------------------------------------------------- > > Key: JBAS-3257 > URL: http://jira.jboss.com/jira/browse/JBAS-3257 > Project: JBoss Application Server > Issue Type: Patch > Security Level: Public(Everyone can see) > Components: Clustering > Environment: Solaris, use gnu patch to apply patchfile: > /opt/gnu/bin/patch < patch.txt > Reporter: Jerry Gauthier > Assigned To: Jerry Gauthier > Attachments: patch.txt > > > Reported by Thomas Wenckebach - see JBCLUSTER-94 > Consider the following setting: > In multi home cluster environments you might want to bind the HANamingService Port to a High Available (virtual) IP address, whereas the NamingService Port would be a local ("real") IP address in this case (different LANs). Note that it is strictly mandatory in this setting to also bind the RmiPort of HANamingService to a local IP address, since it is referenced internally via the system property java.rmi.server.hostname - a conceptual flaw, since it is also used for referencing the NamingService. Consequently, it is a must to bind both NamingService and HANamingService RmiPorts to the same interface. From this fact follows the necessity to bind HANamingService RmiPort to an interface different from the one used by HANamingService Port! > Simply do the following: > $> cd jboss-4.0.3SP1-src/cluster/src/main/org/jboss/ha/jndi > $> /opt/gnu/bin/patch < patch.txt > ( please find patch.txt attached! ) -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2292) DistributedReplicantManager does not honor jmx service dependencies when notifiyng a node removal

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2292?page=all ] Brian Stansberry updated JBAS-2292: ----------------------------------- Fix Version/s: No Release Fix version "No Release" means "not sure when, but not soon." > DistributedReplicantManager does not honor jmx service dependencies when notifiyng a node removal > ------------------------------------------------------------------------------------------------- > > Key: JBAS-2292 > URL: http://jira.jboss.com/jira/browse/JBAS-2292 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: JBossAS-4.0.2 Final > Environment: Jboss 4.0.2, > WinXP > JDK 1.5 > Reporter: janssk1 > Assigned To: Brian Stansberry > Fix For: No Release > > > We are using some HASingletonServices. These services use the HAJNDI tree to lookup other services. > Both the HASingletonservices and the HAJNDI service are notified if a node (eg the master) is removed from the cluster. However, the order seems to be random. If the master goes down, the HASingletonservce seems to be notified first. It tries to start the singleton on another host. While starting, it uses the HAJNDI, but this one still tries to connect to the old server, leading to NamingExceptions. > Since i added a jmx depencency from the singleton service to HAJNDI, i would expect that the HAJNDI gets notified first. That would fix my problem. > I looked in the code of the DistributedReplicantManagerImpl and it seems that this one does not keep track of the order in which keys are registered. I quickly changed all HashMap and HashSet instantiations of this class to LinkedHashMap and LinkedHashSet instantiations, and now my problem is fixed. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2790) JBento setup improvements

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2790?page=all ] Brian Stansberry closed JBAS-2790. ---------------------------------- Resolution: Rejected The described improvements are done, but I'm closing as "Rejected" as this shouldn't be in the AS release notes -- doing it only indirectly impacts the AS. > JBento setup improvements > ------------------------- > > Key: JBAS-2790 > URL: http://jira.jboss.com/jira/browse/JBAS-2790 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service, Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Minor > > Currently tweaking aspects of the app server config for our JBento environment is a pain, as all tweaks have to be copied to the various /server/xyx folders. > Create a config folder in the jbento dir, and store the various configurable files there. Then in the server/xyz folders, have symlinks pointing to these files. > Include: > tc5-cluster-service.xml > jgroups.jar (various releases, with a symlink pointing to the one in use) > jboss-cache.jar (as above) > jboss-web.xml > log4j.xml -- 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, 8 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 September 2006