Clustered invocation design
by David M. Lloyd
There are at least two basic paths we can follow for clustered
invocation based on the current architecture. The right choice is going
to depend primarily upon the expected use cases, which I am not in a
position to properly judge.
Option 1: Clustered Invocation Transport
----------------------------------------
In this option, we introduce a new "LAN" transport type for invocation
on the cluster. The transport would use direct TCP connections or UDP
messages (or both, depending on request size) to convey the invocation.
The characteristics of this option are as follows:
- Security: reliance on physical network security only (no TLS or
authentication)
- Latency is very low, even to new nodes
- Topology changes can be conveyed as separate asynchronous messages
- Invocations from external networks would happen through a proxy node,
with Remoting being bridged to the LAN, to perform security functions
Option 2: Load-balanced Remoting Connections
--------------------------------------------
In this option, we rely on the client to establish one or more Remoting
connection(s) to one or more of the nodes of the cluster. Logic in the
client will be used to determine what connection(s) to use for what
clusters. We have the option of automatically connecting as topology
changes or requiring the user to set up the connections in advance.
Note that automatic connection cannot work in the case of
user-interactive authentication. Characteristics:
- Security: full authentication and TLS supported
- Latency is low once the connection is established, however there is
some overhead involved in authentication and security negotiation
- Topology changes should be asynchronous notifications
- Each connection has to be separately authenticated
- Automatically establishing connections is not presently supported, so
we'd need a bit of infrastructure for that. Deal with user-interactive
authentication. Deal with connection lifecycle management. Deal with
configuration. This will be a point of fragility
Summary
-------
For both options, we have to determine an appropriate load-balancing
strategy. The choice of direction will affect how our clustering and
transaction interceptors function. We also have to suss out the logic
around dealing with conflicting or wrongly-ordered topology updates;
hopefully our existing policies will continue to apply.
--
- DML
12 years, 4 months
7.1.0.Beta1b Release
by Jason T. Greene
This week we discovered an unintentional compatibility problem in our
management protocol. The cause was that the protocol in master had been
slightly updated in an incompatible way to better support SASL
scenarios, BUT the protocol version was not correctly incremented. This
means that 7.1.0.Beta1 can not successfully communicate with 7.0.x and
vice versa. This also means that JBoss Tools was unable to communicate
with both versions without having two separate plugins.
We decided that since this was just a Beta release, the best solution is
to correct the problem and release a patched Beta1 (called Beta1b).
Beta1b now has transport compatibility in both directions with 7.0.x as
expected. Beta1, however, will be forever incompatible. For this reason,
I have removed Beta1 from the download site.
In addition to the compatibility problem, we also discovered that the
Beta1 distribution was using improper file permissions on the
mgmt-users.properties files. This is a potential security issue if
someone does not intentionally make these files unreadable to other
users. This has been corrected. The zip and tar.gz distribution have the
correct unix 600 permissions.
For the CR1 and Final releases we will be doing additional compatibility
testing to prevent this from happening in the future.
Thanks,
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
12 years, 4 months
xml-resolver depdency
by Jim Ma
Hi,
Webserice component needs xml-resolver.jar to restore the catalog
function for cxf. I saw it is in the banned dependency list.
Is there alternative dependency for this ? or is there any problem if I
remove it from list and add this dependency only for org.apache.cxf
module ?
Thanks,
Jim
12 years, 4 months
No config XSLT transform for basic integration tests (#751)
by Thomas Diesler
The XSLT transform that I need does more than just tweak the ports.
The general requirement would be that a set/group of test can do a
transformation of the original config before it runs. This works for
smoke tests, which run against a transformed server config (i.e.
target/jbossas-smoke/configuration) but not for the basic integration tests.
-thomas
On 12/01/2011 01:16 PM, Kabir Khan wrote:
> As suggested on the mailing list last week. If we change the config files to use port-offset="${jboss.port.offset:0}" and make the tests use -Djboss.port.offset=??? instead there might not be any need for xslt to change the portes.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/jbossas/jboss-as/pull/751#issuecomment-2974043
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12 years, 4 months
No validation of deployment descriptors
by Thomas Diesler
Folks,
this is related to
[AS7-2854 <https://issues.jboss.org/browse/AS7-2854>] JSR88 does
not validate deployment descriptors
I wonder whether it is the correct approach to validate the DDs in the
JSR88 layer. It seems more natural/correct to validate the DDs in the
subsystem that consumes the deployment. The behaviour I would expect is
that the (invalid) deployment reaches the server, fails during deploy
and that the deployment failure is communicated back to the jsr88 layer.
Thoughts?
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12 years, 4 months
Attributes versus attributes
by David M. Lloyd
In our management model we have the terms "resources" and "attributes",
where resources are more or less defined as collections of attributes
with an address.
In our configuration file, we use XML which includes "elements" and
"attributes". I've noticed that in many cases, subsystems have taken it
as implied that a management attribute must be mapped directly to an XML
attribute. However, this is not the case.
In particular, our subsystem root XML elements should NOT have
attributes on the <subsystem> element. Due to the way that the XML
namespace is declared, attributes on this XML element are hard to see
and it may be confusing for users.
It is OK (and recommended even) to use nested XML elements for
management attributes. In particular we should always do this:
1) When declaring a subsystem top-level management attribute
2) When a nested management resource could, now or in the future, have
more than one or two attributes
Stylistically, often the only time you should really have more than one
XML attribute on an element is when you are dealing with a compound
value such as a time unit where you have the unit and the quantity, and
that sort of thing.
If you have created a subsystem element with top-level XML attributes,
please take a moment to fix it so we can have a clean configuration file
for CR1. Thanks.
P.S. don't make me bust out the "git annotate"!
--
- DML
12 years, 4 months
Intermittent channel closed errors
by Jaikiran Pai
Anyone looking at the intermittent "Channel Closed" errors when running
the tests? If no one's working on it, then I'll take a look and see
what's wrong sometime this week.
-Jaikiran
12 years, 4 months
