Subresource references
by Heiko Braun
Requesting a server group resource I get this:
{
[INFO] "PROPERTY_VALUE" : {
[INFO] "other-server-group" : {
[INFO] "profile" : "default",
[INFO] "jvm" : {"default" : {
[INFO] "type" : null,
[INFO] "agent-lib" : null,
[INFO] "agent-path" : null,
[INFO] "debug-enabled" : null,
[INFO] "debug-options" : null,
[INFO] "env-classpath-ignored" : null,
[INFO] "environment-variables" : null,
[INFO] "heap-size" : "64m",
[INFO] "max-heap-size" : "512m",
[INFO] "java-agent" : null,
[INFO] "java-home" : null,
[INFO] "jvm-options" : null,
[INFO] "permgen-size" : null,
[INFO] "max-permgen-size" : null,
[INFO] "stack-size" : null,
[INFO] "system-properties" : null
[INFO] }},
[INFO] "deployment" : {},
[INFO] "socket-binding-group" : "standard-sockets"
[INFO] }
[INFO] }
[INFO] },
The pice that's causing me a headache is again the JVm property.
Can we agree that subresources like the JVM in this case are always referenced as ModelNode's of type
property? Similar to the server-group itself? Currently it's returned as type Object, with a property of name 'jvm'
This would simplify the way to get hold of the subresource name.
Ike
13 years
Requirements and Design Proposal: AS7 TestSuite
by Andrew Lee Rubinger
Looks like a lot of us have different ideas for what the AS7 Integration
TestSuite should consist of, so I'll kickoff with what I believe is the
first design proposal towards getting coverage focused on the end-user
(not certifying our own internals).
I suspect this breaks down into two categories, which may be modelled as
separate modules under the existing "testsuite" aggregator parent:
* Specification
* AS-specific APIs
This isn't difficult work, though I do think it's important we consider
some hard rules. IMO we should be developing these suites as if we were
application developers, not wearing our server dev hats.
----------------
[End Goal]
1) No compile-time dependencies in the module except for what's
absolutely necessary.
For the spec suite, this means: JDK and EE Spec APIs only in the
compilation classpath. Testable asset sources and resources (ie. EJBs,
Servlets, etc) would live under src/main/* to enforce that. Only the
tests themselves would be located under "src/test/*".
The AS-specific API suite may also add in our own APIs to the
compilation classpath, but the line should end there. In "test" scope
we can place all runtime dependencies.
For the specification suite, AS-specific grammars like our own
deployment descriptors are fine; these are in many ways equivalent to
the TCK porting layer. We're not building a TCK; we're showing that our
implementation supports the features advertised.
2) Every single new test created is to have an associated JIRA.
We all remember the nightmare it was when the old AS4-6 suite would fall
down. We'd comb through each test, at times trying to determine its
purpose. By linking to JIRA we get history of intent, which acts as a
nice record even in the case that the test isn't so well-documented.
I'd argue that tests are a bigger asset than our code, and we should be
thinking about these in terms of long-term maintenance to outlive any
specific impl.
3) Documentation
Alongside the JIRA reference, a quick note about we're looking to
accomplish is something I find very helpful. I don't personally buy the
argument that code is self-documenting if written well. It gets
refactored and stale over time.
4) Run-mode profiles
Arquillian provides a wonderful abstraction such that we can get
coverage for AS in both remote managed *and* embedded modes without
changing the test itself. To certify that everything is working as
advertised no matter the runtime, we should be able to run the same
suite in standalone, domain, and embedded modes (generally speaking).
5) Porting of AS6 Tests
There's no discounting the value this coverage has given us, though I
question the purpose of a lot of these tests. I think a great majority
of these need to come into the new codebase, refactored to align if needed.
----------------
[Current State]
Here[1] is an example of what I believe to be a simple, well-written
test, with the exception that the tested Servlet and EJB are in the same
test source folder.
The current "testsuite" aggregator contains modules which mix our
end-user certification stuff alongside internals, so I think these
should be separated out.
A lot of this is set up in some fashion already, but I would like to see us:
1) Agree upon a strict scope for each type of testsuite along the lines
of my points above, once we reach agreement
2) Upgrade to ARQ 1.0.0.Alpha5 (which implies ShrinkWrap
1.0.0-alpha-12), just released tonight. Currently AS is on a forked
release of ARQ for OSGi purposes, and these changes, if necessary, need
to get upstream so we can do upgrades.
It's clear that AS7 has made full-steam-ahead progress since last
summer, and with a little organization our testsuite can give us a great
view of where we stand, from an end-user's perspective, with minimal
investment.
S,
ALR
[1]
https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/src...
13 years
Datasource 'metrics' ?
by Heiko W.Rupp
Hi,
resource description for database gives (and more) - these are just examples
>From the previous experiences, I do not think those two (and some more) are metrics
in the classical sense of "value that changes when the server runs" - as opposed to
e.g. number-of-connections-in-pool.
Are those marked as metric on purpose?
pilhuhn
"blocking-timeout-wait-millis" : {
"description" : "The blocking-timeout-millis element indicates the maximum time in milliseconds to block while waiting for a connection before throwing an exception. Note that this blocks only while waiting for a permit for a connection, and will never throw an exception if creating a new connection takes an inordinately long time.",
"type" : {
"TYPE_MODEL_VALUE" : "LONG"
},
"required" : false,
"access-type" : "metric",
"storage" : "runtime"
},
"idle-timeout-minutes" : {
"description" : "The idle-timeout-minutes elements indicates the maximum time in minutes a connection may be idle before being closed. The actual maximum time depends also on the IdleRemover scan time, which is 1/2 the smallest idle-timeout-minutes of any pool.",
"type" : {
"TYPE_MODEL_VALUE" : "LONG"
},
"required" : false,
"access-type" : "metric",
"storage" : "runtime"
},
13 years
Crashes when attaching debugger to AS7 Controller
by Darran Lofthouse
Just a FYI if anyone is looking into the crash issue when attaching a
debugger to a HostController.
It appears that if the first breakpoint is set in the
HostControllerBootstrap stage of start up then debugging works.
However if a breakpoint is set for after the domain controller
initialisation has occurred then the JVM will crash.
So something in between these two steps seems to be causing it.
Regards,
Darran Lofthouse.
13 years
Upload 2 files with the same name fails
by Heiko W.Rupp
Hi,
suppose I have a domain with 2 server groups A and B and two times a foo.war file in version A and B.
Uploading to the domain works, and I get different hashes back
{"outcome":"success","result":{"BYTES_VALUE":"7jgpMVmynfxpqp8UDleKLmtgbrA="},"compensating-operation":null}
sha: 7jgpMVmynfxpqp8UDleKLmtgbrA=
ok.
As I understand next step is now to add this to /deploment/test.war:add(hash= .<from above> , name="test.war")
And here I already have the previous version added, so that new add fails:
Json to send: {"address":[{"deployment":"test.war"}],"operation":"add","hash":{"BYTES_VALUE":"7jgpMVmynfxpqp8UDleKLmtgbrA="},"name":"test.war"}
java.lang.AssertionError: {"outcome":"failed","result":{"domain-failure-description":[{"java.lang.IllegalStateException":"Resource at address [(\"deployment\" => \"test.war\")] already exists"}]}
I think it should be allowed to have multiple files with the same name - especially as the files can be identified via <name,hash>
Heiko
13 years
Should I be able to ls a socket-binding in the admin shell?
by Scott Stark
When I go into the admin shell and navigate down to the socket-binding
in the standard-sockets, tab completion shows the available bindings,
but I am unable to ls any particular socket-binding. I would expect that
when I ls socket-binding-group=standard-sockets/socket-binding=http I
would see the attributes of the node. Is that correct? This is what I see:
[localhost:9999 /] ls socket-binding-group=standard-sockets/socket-binding=
socket-binding=http
socket-binding=https
socket-binding=jmx-connector-registry
socket-binding=jmx-connector-server
socket-binding=jndi
socket-binding=messaging
socket-binding=messaging-throughput
socket-binding=osgi-http
socket-binding=remoting
socket-binding=txn-recovery-environment
socket-binding=txn-socket-process-id
socket-binding=txn-status-manager
[localhost:9999 /] ls
socket-binding-group=standard-sockets/socket-binding=jndi
[localhost:9999 /] ls
socket-binding-group=standard-sockets/socket-binding=jndi
[localhost:9999 /] ls socket-binding-group=standard-sockets/socket-binding
jndi jmx-connector-registry jmx-connector-server
http https osgi-http
remoting txn-recovery-environment txn-status-manager
txn-socket-process-id messaging messaging-throughput
[localhost:9999 /] ls
socket-binding-group=standard-sockets/socket-binding=http
[localhost:9999 /] ls
socket-binding-group=standard-sockets/socket-binding='http'
[localhost:9999 /]
The exceptions seen on the server console are of the form:
18:32:47,658 ERROR [org.jboss.as.controller] (pool-2-thread-4) operation
("read-children-types") failed - address: ([
("socket-binding-group" => "standard-sockets"),
("socket-binding" => "'http'")
]): java.util.NoSuchElementException: No child ''http'' exists
at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:362)
at
org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:298)
at org.jboss.dmr.ModelNode.require(ModelNode.java:703)
at org.jboss.as.controller.PathAddress.navigate(PathAddress.java:233)
at
org.jboss.as.controller.BasicModelController.getOperationSubModel(BasicModelController.java:286)
at
org.jboss.as.controller.BasicModelController$2.getOperationContext(BasicModelController.java:94)
at
org.jboss.as.controller.BasicModelController.execute(BasicModelController.java:257)
at
org.jboss.as.controller.BasicModelController.execute(BasicModelController.java:216)
at
org.jboss.as.controller.BasicModelController.execute(BasicModelController.java:77)
at
org.jboss.as.controller.SynchronousOperationSupport.execute(SynchronousOperationSupport.java:88)
at
org.jboss.as.controller.AbstractModelController.execute(AbstractModelController.java:40)
at
org.jboss.as.controller.remote.ModelControllerOperationHandlerImpl$ExecuteSynchronousOperation.sendResponse(ModelControllerOperationHandlerImpl.java:187)
at
org.jboss.as.protocol.mgmt.ManagementResponse$2.handle(ManagementResponse.java:119)
at
org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:59)
at
org.jboss.as.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:254)
at
org.jboss.as.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:213)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
13 years
problem creating datasources
by Heiko Braun
Please see the following sequence of commands. It seems that the driver is created, also the second operation returns a "failed" status.
[localhost:9999 /] /profile=default/subsystem=datasources/jdbc-driver=hypersonic:add(driver="com.h2database.h2")
{
"outcome" => "failed",
"result" => {"server-groups" => {"main-server-group" => {
"server-one" => {
"host" => "local",
"response" => {
"outcome" => "failed",
"failure-description" => "org.jboss.msc.service.DuplicateServiceException: Service jboss.jdbc-driver.\"org.h2.Driver\".1.2 is already registered"
}
},
"server-two" => {
"host" => "local",
"response" => {
"outcome" => "failed",
"failure-description" => "org.jboss.msc.service.DuplicateServiceException: Service jboss.jdbc-driver.\"org.h2.Driver\".1.2 is already registered"
}
}
}}},
"failure-description" => "Operation was not applied successfully to any servers"
}
[localhost:9999 /] /profile=default/subsystem=datasources/jdbc-driver=hypersonic:add(driver="hypersonic-jdbc-driver")
{
"outcome" => "failed",
"result" => {"domain-failure-description" => [("java.lang.IllegalStateException" => "Resource at address [
(\"profile\" => \"default\"),
(\"subsystem\" => \"datasources\"),
(\"jdbc-driver\" => \"hypersonic\")
] already exists")]}
}
[localhost:9999 /] /profile=default/subsystem=datasources:read-children-names(child-type=jdbc-driver)
{
"outcome" => "success",
"result" => [
"com.h2database.h2",
"hypersonic"
],
"compensating-operation" => undefined
}
13 years
Datasource operations: Inconsistent state after failure
by Heiko Braun
[localhost:9999 /] /profile=default/subsystem=datasources/data-source="custom-datasource-name":add
{
"outcome" => "failed",
"result" => {"server-groups" => {"main-server-group" => {
"server-one" => {
"host" => "local",
"response" => {
"outcome" => "failed",
"failure-description" => "Failed to create DataSource instance for [{
\"operation\" => \"add\",
\"address\" => [
(\"subsystem\" => \"datasources\"),
(\"data-source\" => \"custom-datasource-name\")
]
[...]
And then a subsequent read operation blows up:
{
"operation" : "read-children-resources",
"address" : [
{
"PROPERTY_VALUE" : {
"profile" : "default"
}
},
{
"PROPERTY_VALUE" : {
"subsystem" : "datasources"
}
}
],
"child-type" : "data-source"
}
[Host Controller] 10:18:06,349 ERROR [org.jboss.as.controller] (pool-2-thread-21) operation ("read-children-resources") failed - address: ([
[Host Controller] ("profile" => "default"),
[Host Controller] ("subsystem" => "datasources")
[Host Controller] ]): java.lang.IllegalArgumentException
[Host Controller] at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:124)
[Host Controller] at org.jboss.dmr.ModelNode.keys(ModelNode.java:1085)
[Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ReadResourceHandler.readModel(GlobalOperationHandlers.java:128)
13 years
