Embedding a WF instance in the CLI
by Brian Stansberry
Moving a thread to the dev list.
This is about some prototyping I've been doing on weekends 'cause I'm
bored with my regular tasks. I've been playing with direct local
administration of a WF installation via the CLI without requiring a
socket-based connection. The general use case is initial setup type
activities where the user doesn't want to have to launch a WF server or
HC process and potentially have it be visible on the network.
https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
desire some folks have expressed in being able to do configuration
without first having to edit any xml to avoid port conflicts on 9990 or
9999.
This isn't a major initiative or big priority or anything at this point.
Just something I find interesting and perhaps you will too.
On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
> Neat :) Yes, figuring out the module path is biting everywhere.
> For file system path command line arguments there is a specialized
> FileSystemPathArgument.
>
Thanks; I'll switch to that.
>
> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>> Copying Heiko Braun as he expressed some interest in the topic.
>>
>> BTW, I played with this a bit more last weekend and was able to start an
>> embedded server inside the CLI easily enough. See [1] for very raw
>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>
>> [disconnected/] embed-server
>>
>> There are a couple issues I see, besides the HC stuff I mentioned in my
>> last message.
>>
>> 1) If the CLI is started in a non-modular environment via java -jar
>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>> the jar. And then the embed-server command would need params specifying
>> the location of JBOSS_HOME, possibly module path etc. But it could embed
>> a server installed in any accessible filesystem location.
>>
>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>> running from a WF dist in a modular environment and the embedded server
>> modules are coming from the CLI's own module path. It would be more
>> effort to support embedding a server based on some other module path.
>> Maybe it's no big deal; maybe it's really hard. :)
>>
>> 2) The console logging from the embedded server goes to stdout mixed in
>> with the CLI output. Maybe that's good, maybe it's bad.
>>
>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>
>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>> I was poking around at this for an hour or so over the weekend.
>>>
>>> The standalone case seems pretty straightforward. Seems the existing
>>> embedded server API could work readily enough. The
>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>> ModelControllerClient.
>>>
>>> The domain case is much harder, as the CLI wants a HostController, not a
>>> ProcessController. I'd really like this to use an in-VM client, not a
>>> remote one, so I don't like having the CLI embed a PC and then the HC is
>>> an external process. My thoughts of the morning are to allow inverting
>>> the HC/PC relationship for this kind of usage. That is, remove
>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>> launches HC, and then the HC creates an in-process PC-ish component (not
>>> a separate process) to manage the server lifecycles. There could be all
>>> sorts of problems with that; it's just the thought for the morning.
>>>
>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>> Embedding the AS is the best starting point to achieve that! And more
>>>> fun, I agree :)
>>>>
>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>> And to think my reason for opening the Jira was just for a common
>>>>> way to
>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>
>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>> Wow! Indeed :)
>>>>>>>
>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>> only
>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>
>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>> implementation of all of them would be based in the server; the
>>>>>> "client"
>>>>>> aspect of the CLI would just use the management interface. The
>>>>>> difference between an embedded mode and what we have now would
>>>>>> just be
>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>> have
>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>> client.
>>>>>>
>>>>>>> But it would still mean the server/controller would have to actually
>>>>>>> provide implementations of that functionality and expose it to the
>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>
>>>>>> Yep.
>>>>>>
>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>> remote
>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>
>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>> probably
>>>>>>> easier to implement at this point.
>>>>>>>
>>>>>>
>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>> thread
>>>>>> where I briefly get into this general area too.
>>>>>>
>>>>>>> Alexey
>>>>>>>
>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>> Hi Alexey,
>>>>>>>>
>>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
>>>>>>>> into
>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>> interesting.
>>>>>>>>
>>>>>>>>
>>>>>>>> -------- Original Message --------
>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>> move it
>>>>>>>> into the CLI
>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>> From: Darran Lofthouse (JIRA) <issues(a)jboss.org>
>>>>>>>> To: brian.stansberry(a)redhat.com
>>>>>>>>
>>>>>>>>
>>>>>>>> [
>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin....
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ]
>>>>>>>>
>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>> ----------------------------------------
>>>>>>>>
>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>> this
>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>> SSL
>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>> enablement we talked about in Brno - managing an embedded instance
>>>>>>>> could
>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>
>>>>>>>> I can see this task may end up coming back my way combined with the
>>>>>>>> other stuff ;-)
>>>>>>>>
>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>> ---------------------------------------------------
>>>>>>>>>
>>>>>>>>> Key: WFLY-3288
>>>>>>>>> URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>> Project: WildFly
>>>>>>>>> Issue Type: Feature Request
>>>>>>>>> Security Level: Public(Everyone can see)
>>>>>>>>> Components: Domain Management, Scripts
>>>>>>>>> Reporter: Darran Lofthouse
>>>>>>>>> Fix For: Awaiting Volunteers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Within the add-user utility it is difficult to handle situations
>>>>>>>>> where
>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>> way to
>>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>> there to
>>>>>>>>> handle this.
>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>> special
>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>> could be
>>>>>>>>> the first step to make this possible.
>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>> comments
>>>>>>>>> here are just a starting point.
>>>>>>>>
>>>>>>>> --
>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>> administrators
>>>>>>>> For more information on JIRA, see:
>>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 years, 3 months
JMX Console over Web Admin Console
by Sebastian Łaskawiec
Hi
One of our projects is based on JBoss 5.1 and we are considering migrating
it to Wildfly. One of our problems is Web based JMX Console...
We have pretty complicated production environment and Web based JMX console
with basic Auth delegated to LDAP is the simplest solution for us.
I noticed that there was a ticket opened for porting legacy JMX Console:
https://issues.jboss.org/browse/WFLY-1197.
However I think it would be much better idea to to have this functionality
in Web Administraction console. In my opinion it would be great to have it
under "Runtime" in "Status" submenu.
What do you think about this idea?
Best Regards
--
Sebastian Łaskawiec
9 years, 11 months
2 instance cluster in master/slave
by Arun Gupta
Trying to following the instructions at:
https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto
This shows how to setup a 2-instance cluster in master/slave where
master is on my laptop and slave is on a Raspi. Couple of questions
...
1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ?
<domain-controller>
<remote host="10.211.55.7" port="9999"/>
</domain-controller>
FTR it only works with 9999, not with 9990.
Domain Controller shows the message:
[Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host
Controller Service Threads - 28) JBAS010918: Registered remote slave
host "slave", WildFly 8.1.0.CR2 "Kenny"
2). Master is throwing the following exception:
22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status]
(ProcessController-threads - 3) JBAS012017: Starting process
'Server:server-one'
[Server:server-one] Error occurred during initialization of VM
[Server:server-one] Server VM is only supported on ARMv7+ VFP
22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status]
(reaper for Server:server-one) JBAS012010: Process 'Server:server-one'
finished with an exit status of 1
[Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller]
(ProcessControllerConnection-thread - 2) JBAS010926: Unregistering
server server-one
[Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller]
(Controller Boot Thread) JBAS010922: Starting server server-two
22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status]
(ProcessController-threads - 3) JBAS012006: Failed to send data bytes
to process 'Server:server-one' input stream: java.io.IOException:
Stream closed
at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434)
[rt.jar:1.7.0_40]
at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40]
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
[rt.jar:1.7.0_40]
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
[rt.jar:1.7.0_40]
at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
[rt.jar:1.7.0_40]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
[jboss-threads-2.1.1.Final.jar:2.1.1.Final]
22:15:26,573 ERROR [org.jboss.as.protocol.connection]
(ProcessController-threads - 3) JBAS016610: Failed to read a message:
java.io.IOException: Stream closed
at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434)
[rt.jar:1.7.0_40]
at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40]
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
[rt.jar:1.7.0_40]
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
[rt.jar:1.7.0_40]
at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
[rt.jar:1.7.0_40]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223)
[wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
[jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Same error for server-two as well.
Trying to explicitly start server-three on slave gives the same error.
This is all using 8.1 CR2.
Any idea what might be wrong ?
Thanks
Aru
--
http://blog.arungupta.me
http://twitter.com/arungupta
10 years
wildfly 8.1RC2 refuse to serve *.zip files (404)
by Andrei Tchijov
Hi,
Sorry to bother (if this is wrong list to ask), but I wonder if anybody can help me with following problem:
We have an application deployed on wildfly which among other things serves few static files (*.html, *.json and *.zip). Everything works as it should in 8.0.0Final. However, in 8.1RC2 - *.html and *.json files do work, but *.zip files report 404. Nothing changed on our side - the very same WAR file gets deployed in both cases.
Your help will be highly appreciated,
Cheers,
Andrei Tchijov
10 years
--force and --server-groups
by Arun Gupta
Deploying a WAR file to a server-group gives ...
[domain@10.0.0.27:9990 /] deploy http-1.0-SNAPSHOT.war
--server-groups=other-server-group
'http-1.0-SNAPSHOT.war' already exists in the deployment repository
(use --force to replace the existing content in the repository).
Specifying --force gives ...
[domain@10.0.0.27:9990 /] deploy http-1.0-SNAPSHOT.war --force
--server-groups=other-server-group
--force only replaces the content in the deployment repository and
can't be used in combination with any of --disabled, --server-groups
or --all-server-groups.
How do I force deploy the WAR to a server-group using jboss-cli ?
Arun
--
http://blog.arungupta.me
http://twitter.com/arungupta
10 years
[POLL] 8.1 Patch Or Not
by Jason Greene
So we noticed two problems with releasing the patch for 8.1.0.Final
1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final “disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar “disabling”, so future patches do not have this problem.
2. It’s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO).
So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)?
If there is enough demand considering 1 & 2 I would be happy to release one.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
10 years
[POLL] 8.1 Patch Or Not
by Jason Greene
So we noticed two problems with releasing the patch for 8.1.0.Final
1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final “disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar “disabling”, so future patches do not have this problem.
2. It’s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO).
So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)?
If there is enough demand considering 1 & 2 I would be happy to release one.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
10 years
Disabling parallelism by tweaking java.util.concurrent.ForkJoinPool.common.parallelism
by Emmanuel Hugonnet
Hi,
Yesterday there was a presentation of the Java8 Stream API at the local JUG.
According to the speaker (Paul Sandoz) parallelism should be disabled in webapps because :
"...a machine serving web requests is usually sized/configured to maximize throughput. If web application code was using parallel streams
then CPU resources would be consumed computing results that could otherwise be used to serve other web requests. A stream computation
running on a fork/join pool will not block, it will try and go as fast as possible using as many resources as possible."
What do you think ?
Emmanuel
10 years
