[JBoss JIRA] (WFCORE-800) Support file in management operation
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-800?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFCORE-800:
------------------------------------
[~jdenise] your proposal looks good enough for my use case. We can resolve this RFE if there is already a solution to achieve the same result
> Support file in management operation
> ------------------------------------
>
> Key: WFCORE-800
> URL: https://issues.jboss.org/browse/WFCORE-800
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Alpha6
> Reporter: Jeff Mesnil
> Assignee: Jean-Francois Denise
> Labels: affects_elytron
>
> Working on WFLY-4683, I want to add 2 management operations :export-journal and :import-journal that export/import the journal from the messaging-activemq server resource.
> The :export-journal operation is similar to the :take-snapshot operation and it is acceptable that the dumped file (created internally by Artemis) is stored on the server-side in a well-know location
> However, I'd like to pass such a file to the :import-journal (specified by a dump attribute) so that the admin does not need to copy the dumped file to the server's host (or many hosts in domain mode) before calling the :import-journal operation.
> Currently, this is not doable since we can not add a stream to a management operation *from the CLI*. Instead, I have to implement a global command that will execute the client code to create the management operation, read the file and attach it to the operation as a stream.
> Ideally, I would like to specify that my :import-journal takes a dump attribute with the ModelType.FILE (or .URL ?) so that our management clients (both CLI and Web) know that they must attach the stream of the file to the management operation.
> This RFE is to simplify this use case and make it possible to use directly the CLI (and Web) console to upload files without having to create a dedicated client command for that.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7865) We cannot define CS file location outside of EAP directory
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7865?page=com.atlassian.jira.plugin.... ]
Hynek Švábek closed WFLY-7865.
------------------------------
Resolution: Won't Fix
Yes, it works. Thanks [~brian.stansberry]
{code}
/path=java.io.tmpdir:add(path=/tmp)
{code}
> We cannot define CS file location outside of EAP directory
> ----------------------------------------------------------
>
> Key: WFLY-7865
> URL: https://issues.jboss.org/browse/WFLY-7865
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Critical
>
> We aren't able define location of CS file outside of EAP directory. When user has CS file on NFS he isn't able to reach this file.
> Define CS file location to JBOSS_HOME/Standalone/data directory:
> {code}
> /subsystem=elytron/credential-store=CredStore001:add(uri="cr-store://test/cs123.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=jboss.server.data.dir)
> {code}
> When I try set relative to TEMP directory:
> {code}
> /subsystem=elytron/credential-store=CredStore002:add(uri="cr-store://test/cs123.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=java.io.tmpdir)
> {code}
> I get this error
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"java.io.tmpdir\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore002 is missing [jboss.server.path.\"java.io.tmpdir\"]"]
> },
> "rolled-back" => true
> }
> {code}
> *NOTE:*
> *relative-to* is resolved here https://github.com/wildfly-security/elytron-subsystem/blob/c223be428b9a6f...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-333) Provide a management operation to list the servers in a server group (domain mode)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-333?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-333:
---------------------------------------
Assignee: (was: Brian Stansberry)
> Provide a management operation to list the servers in a server group (domain mode)
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-333
> URL: https://issues.jboss.org/browse/WFCORE-333
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Richard Achmatowicz
> Priority: Minor
>
> In domain mode, an end user might want to start one or more servers by hand in a named server group. Obtaining the list of servers in a server group is not readily available: the "group" attribute is embedded in server-config, so we have to drill down into every /host=*/server-config=* combination to find out which servers belong to a specific server group.
> It would improve the user experience to have an operation which shows which servers are in a given server group.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JGRP-2150) More efficient message adding and draining
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2150 at 1/11/17 9:23 AM:
---------------------------------------------------------
Unfortunately, the above two algorithms are incorrect!
I modeled them in TLA+ and the problem is that we can have multiple consumers... Well, this isn't a problem for MaxOneSenderPerThreadPolicy, but it would destroy the FIFO semantics in NAKACK2 and UNICAST3, where only 1 message (or batch) per sender is delivered at a time!
See \[1\] for details. \[2\] contains the correct solution.
\[1\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest2.tla
\[2\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest3.tla
was (Author: belaban):
Unfortunately, the above two algorithms are incorrect!
I modeled them in TLA+ and the problem is that we can have multiple consumers... Well, this isn't a problem for MaxOneSenderPerThreadPolicy, but it would destroy the FIFO semantics in NAKACK2 and UNICAST3, where only 1 message (or batch) per sender is delivered at a time!
See \[1\] for details. \[3\] contains the correct solution.
\[1\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest2.tla
\[2\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest3.tla
> More efficient message adding and draining
> ------------------------------------------
>
> Key: JGRP-2150
> URL: https://issues.jboss.org/browse/JGRP-2150
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JGRP-2150) More efficient message adding and draining
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2150 at 1/11/17 9:23 AM:
---------------------------------------------------------
Unfortunately, the above two algorithms are incorrect!
I modeled them in TLA+ and the problem is that we can have multiple consumers... Well, this isn't a problem for MaxOneSenderPerThreadPolicy, but it would destroy the FIFO semantics in NAKACK2 and UNICAST3, where only 1 message (or batch) per sender is delivered at a time!
See \[1\] for details. \[3\] contains the correct solution.
\[1\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest2.tla
\[2\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest3.tla
was (Author: belaban):
Unfortunately, the above two algorithms are incorrect!
I modeled them in TLA+ and the problem is that we can have multiple consumers... Well, this isn't a problem for MaxOneSenderPerThreadPolicy, but it would destroy the FIFO semantics in NAKACK2 and UNICAST3, where only 1 message (or batch) per sender is delivered at a time!
See \[1\] for details.
\[1\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest2.tla
> More efficient message adding and draining
> ------------------------------------------
>
> Key: JGRP-2150
> URL: https://issues.jboss.org/browse/JGRP-2150
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JGRP-2150) More efficient message adding and draining
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2150:
--------------------------------
Unfortunately, the above two algorithms are incorrect!
I modeled them in TLA+ and the problem is that we can have multiple consumers... Well, this isn't a problem for MaxOneSenderPerThreadPolicy, but it would destroy the FIFO semantics in NAKACK2 and UNICAST3, where only 1 message (or batch) per sender is delivered at a time!
See \[1\] for details.
\[1\] https://github.com/belaban/pluscal/blob/master/MessageBatchDrainTest2.tla
> More efficient message adding and draining
> ------------------------------------------
>
> Key: JGRP-2150
> URL: https://issues.jboss.org/browse/JGRP-2150
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1738) Hint when versions are out-of-date pending restart
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1738?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise closed WFCORE-1738.
----------------------------------------
Resolution: Won't Do
The way to go is for the CLI users to take into account the content of headers. The header says that the server should be restarted. This is what a user should do prior to make requests to the server.
I think that this issue can be closed. Feel free to re-open.
JF
> Hint when versions are out-of-date pending restart
> --------------------------------------------------
>
> Key: WFCORE-1738
> URL: https://issues.jboss.org/browse/WFCORE-1738
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Patching
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
> Priority: Optional
>
> I have a minor usability suggestion. It's merely informational but I think helpful.
> When I was in the CLI tool to apply a version update patch (7.0.0 -> 7.0.1), I wasn't yet aware that I needed to restart the server for it to take effect. So when I afterward typed "version" to confirm the expected version bumps... well, they did not. I was specifically looking to confirm a change in both fields "JBoss AS release" and "JBoss AS product". With that said, it would be useful to add something to the output indicating the information being displayed will no longer be true.
> Illustrated example. Notice the asterisks:
> {code}
> JBOSS_HOME: C:\dev\jboss-eap-7
> JBoss AS release: 2.1.2.Final-redhat-1 "Kenny"(*)
> JBoss AS product: JBoss EAP 7.0.0.GA(*)
> JAVA_HOME: c:\java\jdk1.8.0_45
> java.version: 1.8.0_45
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.45-b02
> os.name: Windows 7
> os.version: 6.1
> (*) Versions subject to change after patch takes effect at restart.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1738) Hint when versions are out-of-date pending restart
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1738?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise reassigned WFCORE-1738:
--------------------------------------------
Assignee: Jean-Francois Denise (was: Alexey Loubyansky)
> Hint when versions are out-of-date pending restart
> --------------------------------------------------
>
> Key: WFCORE-1738
> URL: https://issues.jboss.org/browse/WFCORE-1738
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Patching
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
> Priority: Optional
>
> I have a minor usability suggestion. It's merely informational but I think helpful.
> When I was in the CLI tool to apply a version update patch (7.0.0 -> 7.0.1), I wasn't yet aware that I needed to restart the server for it to take effect. So when I afterward typed "version" to confirm the expected version bumps... well, they did not. I was specifically looking to confirm a change in both fields "JBoss AS release" and "JBoss AS product". With that said, it would be useful to add something to the output indicating the information being displayed will no longer be true.
> Illustrated example. Notice the asterisks:
> {code}
> JBOSS_HOME: C:\dev\jboss-eap-7
> JBoss AS release: 2.1.2.Final-redhat-1 "Kenny"(*)
> JBoss AS product: JBoss EAP 7.0.0.GA(*)
> JAVA_HOME: c:\java\jdk1.8.0_45
> java.version: 1.8.0_45
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.45-b02
> os.name: Windows 7
> os.version: 6.1
> (*) Versions subject to change after patch takes effect at restart.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-421) cli tab-completion: filtering out operations not applicable to a resource
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-421?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise reassigned WFCORE-421:
-------------------------------------------
Assignee: Jean-Francois Denise (was: Alexey Loubyansky)
> cli tab-completion: filtering out operations not applicable to a resource
> -------------------------------------------------------------------------
>
> Key: WFCORE-421
> URL: https://issues.jboss.org/browse/WFCORE-421
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Environment: JBoss AS 7.0.1
> Reporter: Bill Meyer
> Assignee: Jean-Francois Denise
> Priority: Minor
>
> In this example, no Data Sources already exist (clean config).
> If I enter the following into the CLI and hit <tab>:
> /subsystem=datasources/data-source=:<tab>
> I get no operation hints. If I use a bogus resource name that doesn't exist and hit <tab>:
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=DoesNotExistDS:<tab>
> add disable enable flush-all-connection-in-pool
> flush-idle-connection-in-pool read-attribute read-children-names read-children-resources
> read-children-types read-operation-description read-operation-names read-resource
> read-resource-description remove test-connection-in-pool validate-address
> write-attribute
> I get all the operations available. This should be made more consistent. The preference, IMO, would be to not have to specify a bogus name and still get the operations list:
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=:<tab>
> or simpler yet:
> [standalone@localhost:9999 /] /subsystem=datasources/data-source:<tab>
> (no empty equal sign).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months