April 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4604) NamingContext does not take potential AutoDiscoveryAddress XML property overrides when sending discovery requests

by Galder Zamarreno (JIRA)

NamingContext does not take potential AutoDiscoveryAddress XML property overrides when sending discovery requests ----------------------------------------------------------------------------------------------------------------- Key: JBAS-4604 URL: http://jira.jboss.com/jira/browse/JBAS-4604 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Naming Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA Reporter: Galder Zamarreno Assigned To: Brian Stansberry Priority: Minor Bug in org.jnp.interfaces.NamingContext: discoverServer(Hashtable) method String group = DEFAULT_DISCOVERY_GROUP_ADDRESS; ... String discoveryGroup = (String) serverEnv.get(JNP_DISCOVERY_GROUP); if (discoveryGroup != null) group = discoveryGroup; ... iaGroup = InetAddress.getByName(group); .... if (trace) log.trace("Sending discovery packet(" + data + ") to: " + iaGroup + ":" + port); NamingContext code does not take in account possible system property overrides coming from: <attribute name="AutoDiscoveryAddress">${jboss.partition.udpGroup:230.0.0.4}</attribute> AutoDiscoveryAddress used to send discovery messages is controlled via the the default value, 230.0.0.4 or jnp.discoveryGroup property. So, if user sets jboss.partition.udpGroup=224.0.0.1 on startup, DetachedHANamingService$AutomaticDiscovery will listen on 224.0.0.1 while NamingContext sends discovery requests to 230.0.0.4 -- 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

15 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4524) Use JBoss Serialization to serialize non-serializable objects in a clustered web application session.

by Ricardo Arguello (JIRA)

Use JBoss Serialization to serialize non-serializable objects in a clustered web application session. ----------------------------------------------------------------------------------------------------- Key: JBAS-4524 URL: http://jira.jboss.com/jira/browse/JBAS-4524 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.0.5.GA Reporter: Ricardo Arguello Assigned To: Brian Stansberry Priority: Optional If you have a clustered web application (<distributable/>) you can't put non-serializable objects in an HttpSession. JBoss Serialization could be used to support this, as it can serialize non-serializable objects. Initial support for JBoss Serialization was added in JBAS-2921. -- 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

15 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4757) Need a new LBP for Redistirbution of Load When Cluster Membership Changes

by Jimmy Wilson (JIRA)

Need a new LBP for Redistirbution of Load When Cluster Membership Changes ------------------------------------------------------------------------- Key: JBAS-4757 URL: http://jira.jboss.com/jira/browse/JBAS-4757 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA Reporter: Jimmy Wilson Assigned To: Brian Stansberry Priority: Minor Possible implementations: 1) Return to original target. Note I believe this won't work for RMI-based targets (could be wrong). 2) Everyone randomly picks new targets when a new node joins. Bad as this causes max # of failovers. 3) Determine what the new servers are. Say 2 out of 6 are new. Calc a random and see if < .33; if so randomly pick one of the new servers as your target. -- 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

15 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-5090) Use Channel.setInfo() to provide data to JGroups probe

by Brian Stansberry (JIRA)

Use Channel.setInfo() to provide data to JGroups probe ------------------------------------------------------ Key: JBAS-5090 URL: http://jira.jboss.com/jira/browse/JBAS-5090 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Optional Think about ways to take advantage of following from Bela Ban: Okay, I've added an "info" paremeter to Probe, so you can run JGroups/bin/probe.sh -timeout 1000 -query info and this will dump *any* information that was added via Channel.setInfo(String key,Object val). The val will be written to a StringBuilder, so make sure you place only values into info which have a meaningful toString(). This can be used to dump buddy replication information. However, any application which has access to a channel can add information which is useful on a probe, e.g. * JBossCache o Version o Buddy replication info o Number of nodes, attrs o Config info * Clustering o Different clusters a node is part of o Node name o Config info The Probe utility is quick and dirty and - since it uses IP multicasts - cannot dump more than 65K worth of data, so make sure you don't cram everything in there ... -- 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

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5154) docs/examples should include a directory called jgroups with sample configurations

by Galder Zamarreno (JIRA)

docs/examples should include a directory called jgroups with sample configurations ---------------------------------------------------------------------------------- Key: JBAS-5154 URL: http://jira.jboss.com/jira/browse/JBAS-5154 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering, Documentation Affects Versions: JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA Reporter: Galder Zamarreno Assigned To: Brian Stansberry AS should include example JGroups configurations in docs/examples/jgroups for the version distributed, i.e. AS 4.2.2.GA that comes with JGroups 2.4.1.SP3 should include the example configurations from JGroups's conf/ directory in the source code. -- 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

15 years, 8 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-5100) Encapsulate stripping of jvmRoute in SessionReplicationContext

by Brian Stansberry (JIRA)

Encapsulate stripping of jvmRoute in SessionReplicationContext -------------------------------------------------------------- Key: JBAS-5100 URL: http://jira.jboss.com/jira/browse/JBAS-5100 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor For a mod_jk based request, the stripping of the core sesison id from the jvmRoute portion may happen several times in one request. This should just be done once in SessionReplicationContext. -- 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

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5162) Handling of cluster wide RPC call timeouts during AS startup

by Galder Zamarreno (JIRA)

Handling of cluster wide RPC call timeouts during AS startup ------------------------------------------------------------ Key: JBAS-5162 URL: http://jira.jboss.com/jira/browse/JBAS-5162 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Deployment services Affects Versions: JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA Reporter: Galder Zamarreno Assigned To: Brian Stansberry Priority: Minor Handling of cluster wide RPC call timeouts (1 min) during AS startup. See design forum for further information. -- 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

15 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-5305) Loadbalancing and clustering JBOSS using Apache Http server

by Yugant Shah (JIRA)

Loadbalancing and clustering JBOSS using Apache Http server ----------------------------------------------------------- Key: JBAS-5305 URL: http://jira.jboss.com/jira/browse/JBAS-5305 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.2.2.GA Environment: Windows XP Reporter: Yugant Shah Assigned To: Brian Stansberry Priority: Blocker Hello, I have clustered two instances of JBOSS and I have configured the jboss web deployer for load balancing using apache http server. Consider I have 2 instances of Tomcat (embedded in JBOSS) say TOM1 and TOM2. Loadbalancer1 is TOM1 and TOM2 is Loadbalancer2 are configured in Apache server. A request is processed by TOm1 and it goes down(using Ctrl+C) the request is then load balanced to TOM2.In the mean I start TOM1 again. And bring TOM2 down...The request state is transfered to TOM1 and TOm1 restarts the processing of same request. The problem is that TOM1 throws an exception 13:24:40,954 INFO [STDOUT] YUGANT Bean:5 13:24:41,455 INFO [STDOUT] YUGANT Bean:6 13:24:41,957 INFO [STDOUT] YUGANT Bean:7 13:24:42,458 INFO [STDOUT] YUGANT Bean:8 13:24:42,960 INFO [STDOUT] YUGANT Bean:9 13:24:43,477 ERROR [ServerThread] Worker thread initialization failure java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65 ) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) at java.io.ObjectOutputStream$BlockDataOutputStream.flush(ObjectOutputSt ream.java:1631) at java.io.ObjectOutputStream.flush(ObjectOutputStream.java:666) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.s endObjectVersion2_2(JavaSerializationManager.java:121) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.s endObject(JavaSerializationManager.java:95) at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write( SerializableMarshaller.java:120) at org.jboss.remoting.transport.socket.ServerThread.versionedWrite(Serve rThread.java:806) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(Se rverThread.java:606) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.j ava:373) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.jav a:166) 15:06:03,431 INFO [TreeCache] viewAccepted(): [192.168.0.33:1652|17] [192.168.0 .33:1652, 192.168.0.50:2949] 15:06:03,463 INFO [TreeCache] locking the subtree at / to transfer state 15:06:03,479 INFO [StateTransferGenerator_140] returning the state for tree roo ted in /(1024 bytes) 15:06:07,702 INFO [final16] New cluster view for partition final16 (id: 17, del ta: 1) : [192.168.0.33:1199, 192.168.0.50:1199] 15:06:07,702 INFO [final16] I am (192.168.0.33:1199) received membershipChanged event: 15:06:07,702 INFO [final16] Dead members: 0 ([]) 15:06:07,702 INFO [final16] New Members : 1 ([192.168.0.50:1199]) 15:06:07,702 INFO [final16] All Members : 2 ([192.168.0.33:1199, 192.168.0.50:1 199]) And the request is left unprocessed. I am not able to resolve this issue. Thanks in advance. Thanks, Yugant Shah. -- 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

15 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-180) Calling getters/setters cluster wide - covenience feature

by Galder Zamarreno (JIRA)

Calling getters/setters cluster wide - covenience feature --------------------------------------------------------- Key: JBCLUSTER-180 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-180 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Galder Zamarreno Assigned To: Brian Stansberry Priority: Optional We'd like to check the values of an attirbute on all cluster nodes. Is there any quick way to do so? During the startup of your own JMX MBean service you first have to register it with HAPartition using registerRPCHandler method in HAPartition [1]. Provide a service name and your own MBean object as parameters. When checking a value of an attribute of your mbean in the whole cluster you would invoke HAPartition.callMethodOnCluster together with service name parameter provided for registerRPCHandler method. You have to expose this attribute as an operation However, it would be more convenient to just use getter or setter. thanks, -- 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

15 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-4630) Coordinate optimized entity/XPC replication across web and ejb3 tiers

by Brian Stansberry (JIRA)

Coordinate optimized entity/XPC replication across web and ejb3 tiers --------------------------------------------------------------------- Key: JBAS-4630 URL: http://jira.jboss.com/jira/browse/JBAS-4630 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, EJB3, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry See EJBTHREE-1039 and JBAS-4629 for background. For use cases that involve requests that store entities and XPCs in both the web and ejb3 tiers, need to ensure that the process is properly handled. At minimum, need to ensure that the XPC is always deserialized before any managed entities, no matter what the access pattern is. It would also be nice to avoid duplicate serialization of the XPC. -- 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

15 years, 8 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2008