Timeouts for ModelControllerClient calls?
by Rob Stryker
Hi all:
Executing the following code, takes about 5 seconds if the remote server
is down. This code is actually used to see if the remote server is up or
down, so if we could trim this down (ie reduce timeout) through some
API, it'd be great.
ModelNode node = ....etc...;
this.client =
ModelControllerClient.Factory.create(details.getHost(),
details.getManagementPort(), getCallbackHandler());
ModelNode response = client.execute(node);
In stacktrace, I see about 12 steps in, there's a clear timeout of
5000. Any way to override this at the dmr or ModelControllerClient
level? Stacktrace included for completeness. Also, where should I look
in the future to be able to discover the answer myself without hassling
you all? ;)
// This is where we can see a timeout, and where it delays for 5 seconds
ProtocolConnectionUtils.connectSync(ProtocolConnectionConfiguration)
line: 101
// Everything else below does not show a timeout being passed
ProtocolConnectionManager$EstablishingConnection.connect() line: 256
ProtocolConnectionManager.connect() line: 70
ManagementClientChannelStrategy$Establishing(FutureManagementChannel$Establishing).getChannel()
line: 176
RemotingModelControllerClient.getOrCreateChannel() line: 144
RemotingModelControllerClient$1.getChannel() line: 65
ManagementChannelHandler.executeRequest(ActiveOperation<T,A>,
ManagementRequest<T,A>) line: 115
ManagementChannelHandler.executeRequest(ManagementRequest<T,A>, A) line: 98
RemotingModelControllerClient(AbstractModelControllerClient).executeRequest(ManagementRequest<ModelNode,OperationExecutionContext>,
OperationExecutionContext) line: 236
RemotingModelControllerClient(AbstractModelControllerClient).execute(OperationExecutionContext)
line: 141
RemotingModelControllerClient(AbstractModelControllerClient).executeForResult(AbstractModelControllerClient$OperationExecutionContext)
line: 127
RemotingModelControllerClient(AbstractModelControllerClient).execute(ModelNode)
line: 71
12 years, 11 months
Where to register CDI Context for JTA 1.2
by Paul Robinson
Stuart (wildfly-dev in CC too)
I'm implementing JTA 1.2, and part of it is to develop a new CDI context. I'm currently registering that via an Extension in the javax.enterprise.inject.spi.Extension file. The problem with this is that this is a burden on the application developer. Alternatively, I could register it in a DUP in the transactions subsytem. I'd probably have to register it for every deployment, as I don't think I can detect if it's needed.
@pmuir said that you would probably know what I should do.
Thanks,
Paul.
--
Paul Robinson
Web Service Transactions Lead
paul.robinson(a)redhat.com
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
(USA), Charlie Peters (USA)
12 years, 11 months
File upload/manipulation through management API?
by Ondrej Zizka
Hi all,
for the purpose of migration, it would be nice to have a possibility to
upload certain files. Namely:
- create modules (e.g. JDBC drivers)
- copy .properties files - logging, security etc.
- ssh keys, certificates etc.
Is there a chance to have this in Wildfly mgmt API?
It could be limited to the examples above - i.e. one op for
creating/removing a module, one op for copying a file to configuration/ .
Thanks,
Ondra
12 years, 11 months
Help pick the next release code name
by Jason Greene
As you know every release has a codename, and normally it's something we come up with on the day of release, but I'd like to make it more interesting and pick the name at the start of a new release as opposed to at the end.
One name a few of us are quite fond of is "Texugo" but I was thinking of saving that for the Beta or the Final.
Any suggestions?
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
12 years, 11 months
Application shutdown code: recommended approach?
by Thomas Segismont
Hi,
I recently created this BZ for EAP6.1:
Bug 958217 - Unable to call Stateless bean methods from Singleton
PreDestroy callback
https://bugzilla.redhat.com/show_bug.cgi?id=958217
I though I could call any EJB bean from a @Singleton @PreDestroy method
but, as Jaikiran pointed out, the @DependsOn annotation is needed to
prevent dependencies from being shutdown before this last call.
While it is doable to manually list a few dependencies, it is obviously
not an option if your shutdown code virtually needs any of your EJB
beans to be available: in RHQ, we want to be able to shutdown a Quartz
scheduler gracefully, and the jobs running at shutdown might depend on
any EJB bean.
I though of adding a DeploymentUnitProcessor which would automatically
make a "special" @Singleton bean (marked with an annotation) depend on
all over beans in the RHQ deployment.
What do you think?
Thanks and regards,
Thomas
12 years, 11 months
Tgz option download
by Spolti
Hello, everyone,
The wildfly.tgz download link have a problem?
I trying download but stops in 4 mb.
--
Regards,
______________________________________
Filippe Costa Spolti
Linux User n°515639 - http://counter.li.org/
filippespolti(a)gmail.com
+55 34 9679-2388
"Be yourself"
12 years, 11 months
Announcing WildFly 8.0.0.Alpha1!
by Jason Greene
I am happy to formally announce the availability of the first release of WildFly, 8.0.0.Alpha1. The code name is appropriately "WildFly".
The release is available for download here:
http://wildfly.org/download
As recently announced, this is the first in a series of iterative releases that will be following a monthly cadence, with a goal for delivery in November.
Some notable updates include
- Themes, icons, maven gavs, etc now all say WildFly
- Switched default web container to Undertow
(a new non-blocking high-performance web server)
- Significant performance improvements and related features in JPA
- A number of Java EE7 APIs previewed including:
* JSR-503 (JSON-P)
* Servlet 3.1
* JSF 2.2
* JSR-356 (Web Sockets)
* Common Annotations 1.2
* CDI 1.1
- Support for HTTP tunneling the remote management protocols and JMX
(A step towards our one-port profile planned for 8)
- Database backed EJB Timers
- CDI beans now allowed in static modules
- Switched to JDK7 (Java EE7 requires)
- Support for coarse deployment ordering dependencies
- Deployment descriptor overrides
- EC2 discovery support for domain mode using S3
- Dropped CMP, JAXR, JSR-88, and JAX-RPC Support (no longer in Java EE)
- Major bundled third-party Updates
* Infinispan 5.2.5.Final
* HornetQ 2.3.0.Final
* Hibernate 4.2.0.Final
* Narayana 5.0.0.M2
* JBossWS-CXF 4.2.0.Beta1
The full list of 314 resolves issues is available here:
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313721&versi...
As a reminder the main goals that WildFly 8 is targeting are:
- Java EE7
- Patching
- Domain Management Role Based Access Control
- Single Network Port profile
- Runtime performance improvements
If you would like to get involved, come and see us in the #wildfly channel on irc.freenode.org.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
12 years, 11 months
8.0.0.Alpha1 is Tagged!
by Jason Greene
Hello Everyone,
I have tagged 8.0.0.Alpha1 this evening. Unfortunately, due to an IT issue, the upload will not be available on the official wildfly.org site until Monday.
I will send an official, more detailed, release announcement once the build has been promoted.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
12 years, 11 months
