[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
[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
[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
[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
[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
[JBoss JIRA] Created: (JBAS-4629) Optimized replication of entities and extended persistence context in HttpSessions
by Brian Stansberry (JIRA)
Optimized replication of entities and extended persistence context in HttpSessions
----------------------------------------------------------------------------------
Key: JBAS-4629
URL: http://jira.jboss.com/jira/browse/JBAS-4629
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering, Web (Tomcat) service
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Optimize replication of clustered web sessions that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held as a session attribute and those held by the replicated EntityManager.
Currently object identity is maintained by serializing the entire session as one operation (and thus only works reliably if SESSION granularity is used). The entire EM is serialized, including entities that have been flushed to the db. This is inefficient, since the replication is only done to support failover and in the case of node failover, the flushed entities can be restored from the db or the EM's 2nd level cache.
Intent is to:
1) Use JBoss serialization in order to have the ability to alter the serialized form of entities and XPCs.
1) Have Hibernate's EM impl expose getUnflushedChanges()/setUnflushedChanges() methods to support replication of only the unflushed changes held in the XPC, rather than all data.
2) When writing the attributes in the session, check if the object is a managed entity; if so write it's id to the stream rather than the whole object.
3) Deserialization process needs to ensure that any EntityManager is deserialized before the managed entities.
4) Deserialization of a managed entity would involve reading the id from the stream, identifying the EntityManager and doing a find().
5) Sessions should be lazy-deserialized (i.e. only deserialize if needed to handle failover). This is the way web session clustering already works. This is critical, otherwise the cost of the find() operations would likely outweigh the benefits of reducing the amount of replicated data.
Additionally, intent is to allow registration with the container of an impl, say, "ManagedPersistenceContextSerializer". If registered, implementation of many of the steps above would be delegated. JBoss Seam would intend to register an implementation.
--
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
[JBoss JIRA] Created: (JBAS-4816) FirstAvailable - access and update of electedTarget is not atomic
by Galder Zamarreno (JIRA)
FirstAvailable - access and update of electedTarget is not atomic
-----------------------------------------------------------------
Key: JBAS-4816
URL: http://jira.jboss.com/jira/browse/JBAS-4816
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Trivial
Looking at FirstAvailable load balance policy, electedTarget access/update is not synchronised,
however, the chances of having some issues are very small. First, the proxy needs to be shared
by various threads before the electedTarget has been set, but as electedTarget already elected
randomly, the secondary effects of this lack of safety are none.
--
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
[JBoss JIRA] Created: (JBXB-114) Reusing a model group
by Scott M Stark (JIRA)
Reusing a model group
---------------------
Key: JBXB-114
URL: http://jira.jboss.com/jira/browse/JBXB-114
Project: JBoss XML Binding (JBossXB)
Issue Type: Feature Request
Reporter: Scott M Stark
Fix For: JBossXB-2.0.0.CR5
We have an issue with mapping legacy schemas onto the jboss_5_0.xsd environment model group. The jboss_4_2.dtd specifies elements that are in the environment model group, but there are elements like security-identity interleaved with this:
<!ELEMENT session (ejb-name , jndi-name? , local-jndi-name?, call-by-value?,
exception-on-rollback?, timer-persistence?, configuration-name?, invoker-bindings?,
security-proxy? , ejb-ref* , ejb-local-ref* , service-ref*, security-identity? ,
resource-ref* , resource-env-ref*, message-destination-ref* , clustered? ,
cluster-config?, method-attributes?, depends*,
ior-security-config?, port-component*, ejb-timeout-identity?)>
See the org.jboss.test.metadata.ejb.JBoss42UnitTestCase.testExcludedMethods that parses a conforming jboss_4_2.dtd document, but fails to parse with:
org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/home/svn/JBossHead/projects/metadata/trunk/target/eclipse-classes/org/jboss/test/metadata/ejb/JBoss42_testExcludedMethods.xml@46,34
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:194)
...
Caused by: java.lang.IllegalArgumentException: jndiEnvironmentRefsGroup already set
at org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.setJndiEnvironmentRefsGroup(JBossEnterpriseBeanMetaData.java:265)
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:585)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108)
at org.jboss.beans.info.plugins.AbstractPropertyInfo.set(AbstractPropertyInfo.java:182)
at org.jboss.xb.spi.AbstractBeanAdapter.set(AbstractBeanAdapter.java:95)
at org.jboss.xb.builder.runtime.PropertyHandler.handle(PropertyHandler.java:61)
... 41 more
--
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