[JBoss JIRA] (WFCORE-923) Execution timeout for CLI operations
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise updated WFCORE-923:
----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1697
> Execution timeout for CLI operations
> ------------------------------------
>
> Key: WFCORE-923
> URL: https://issues.jboss.org/browse/WFCORE-923
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Lyle Wang
> Assignee: Alexey Loubyansky
> Labels: cli, timeout
>
> It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
> Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
> Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1673) Testsuite: tests for CLI controller aliases
by Martin Schvarcbacher (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1673?page=com.atlassian.jira.plugi... ]
Martin Schvarcbacher updated WFCORE-1673:
-----------------------------------------
Description:
Added integration tests for server aliases defined in jboss-cli.xml
Usage in bin/jboss-cli.xml:
{code:xml}
<controllers>
<controller name="ServerOne">
<protocol>http-remoting</protocol>
<host>localhost</host>
<port>9990</port>
</controller>
</controllers>
{code}
{code:bash}
./bin/jboss-cli.sh --controller=ServerOne --connect
{code}
+*TEST PLAN*+
# set invalid default controller configuration to ensure all settings are being loaded only from controller aliases
# connect to controller alias with all options (protocol, hostname, port) specified
# protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller
was:
Added integration tests for server aliases defined in jboss-cli.xml
Usage in bin/jboss-cli.xml:
{code:xml}
<controllers>
<controller name="ServerOne">
<protocol>http-remoting</protocol>
<host>localhost</host>
<port>9990</port>
</controller>
</controllers>
{code}
{code:bash}
./bin/jboss-cli.sh --controller=ServerOne --connect
{code}
+*TEST PLAN*+
# set invalid default controller configuration to ensure all settings are being loaded only from controller aliases
# connect to controller alias with all options (protocol, hostname, port) specified
# protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller
# <default-protocol use-legacy-override=true> && no protocol specified && port=9999 →use remoting://
# <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol>
# no protocol specified in <default-controller> → use <default-protocol>
> Testsuite: tests for CLI controller aliases
> -------------------------------------------
>
> Key: WFCORE-1673
> URL: https://issues.jboss.org/browse/WFCORE-1673
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Test Suite
> Reporter: Martin Schvarcbacher
> Assignee: Martin Schvarcbacher
> Priority: Minor
>
> Added integration tests for server aliases defined in jboss-cli.xml
> Usage in bin/jboss-cli.xml:
> {code:xml}
> <controllers>
> <controller name="ServerOne">
> <protocol>http-remoting</protocol>
> <host>localhost</host>
> <port>9990</port>
> </controller>
> </controllers>
> {code}
> {code:bash}
> ./bin/jboss-cli.sh --controller=ServerOne --connect
> {code}
> +*TEST PLAN*+
> # set invalid default controller configuration to ensure all settings are being loaded only from controller aliases
> # connect to controller alias with all options (protocol, hostname, port) specified
> # protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6883) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-6883:
--------------------------------------
Summary: A client is not able to invoke EJB's deployed as "HASingleton deployment"
Key: WFLY-6883
URL: https://issues.jboss.org/browse/WFLY-6883
Project: WildFly
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
Reporter: Wolf-Dieter Fink
Assignee: Paul Ferraro
Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-6882:
--------------------------------------
Summary: A client is not able to invoke EJB's deployed as "HASingleton deployment"
Key: WFLY-6882
URL: https://issues.jboss.org/browse/WFLY-6882
Project: WildFly
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
Reporter: Wolf-Dieter Fink
Assignee: Paul Ferraro
Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1239) Deleting of drools project cause error on Windows 10
by Tomas David (JIRA)
Tomas David created DROOLS-1239:
-----------------------------------
Summary: Deleting of drools project cause error on Windows 10
Key: DROOLS-1239
URL: https://issues.jboss.org/browse/DROOLS-1239
Project: Drools
Issue Type: Bug
Components: eclipse plugin
Affects Versions: 6.4.0.Final
Environment: Windows 10
jdk 1.8.0
Reporter: Tomas David
Assignee: Robert (Bob) Brodt
Attachments: error.png, log
If you create a new drools project with all samples and delete it, an error appears. This happens only sometimes on windows 10 machines.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1239) Deleting of drools project cause error on Windows 10
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1239?page=com.atlassian.jira.plugi... ]
Tomas David updated DROOLS-1239:
--------------------------------
Description: If you create a new drools project with all samples and delete it, an error appears. This happens only sometimes on windows 10 machines. See the screenshot and log file. (was: If you create a new drools project with all samples and delete it, an error appears. This happens only sometimes on windows 10 machines.)
> Deleting of drools project cause error on Windows 10
> ----------------------------------------------------
>
> Key: DROOLS-1239
> URL: https://issues.jboss.org/browse/DROOLS-1239
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 6.4.0.Final
> Environment: Windows 10
> jdk 1.8.0
> Reporter: Tomas David
> Assignee: Robert (Bob) Brodt
> Labels: reported-by-qe
> Attachments: error.png, log
>
>
> If you create a new drools project with all samples and delete it, an error appears. This happens only sometimes on windows 10 machines. See the screenshot and log file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2080 at 7/27/16 7:41 AM:
---------------------------------------------------------
Hmm... we could also start from the end and add 'randomness' to an {{IpAddress}}; rather than encoding the IP address and port in the UUID, we could add a 16 byte (or smaller) UUID to {{IpAddress}}.
The reason we abandoned IpAddress a long time ago is that - if the port was fixed - we could run into _reincarnation issues_: a member with address {{192.168.1.3:5000}} crashing and immediately restarting would have the same address {{192.168.1.3:5000}} but still have state from old members (e.g. in {{NAKACK2}}).
Since the combination of IP address and port is pretty unique, we'd only have to add a small amount of randomness (perhaps even configurable) to an {{IpAddress}}. Currently, {{IpAddress}} uses 20 bytes in memory (JOL) and loses 4 due to mapping, so we could use 12 bytes for randomness.
The advantages of this over encoding the IP address in a UUID are:
* To extract an {{IpAddress}} from a UUID when sending a message, we'd need to create a new {{IpAddress}} instance for every message (high allocation rate). When adding some randomness to {{IpAddress}}, we can directly use those
* Encoding an IPv4 address in a UUID takes 6 bytes (4 for the address and 2 for the port), so we have 10 bytes left for randomness in the UUID. For IPv6, the required size is 18 bytes, so we'd need to make the UUID larger to have enough randomness. With the extension scheme, {{IpAddress}} would always contain the same amount of randomness.
was (Author: belaban):
Hmm... we could also start from the end and add 'randomness' to an {{IpAddress}}; rather than encoding the IP address and port in the UUID, we could add a 16 byte (or smaller) UUID to {{IpAddress}}.
The reason we abaondoned IpAddress a long time ago is that - if the port was fixed - we could run into _reincarnation issues_: a member with address {{192.168.1.3:5000}} crashing and immediately restarting would have the same address {{192.168.1.3:5000}} but still have state from old members (e.g. in {{NAKACK2}}).
Since the combination of IP address and port is pretty unique, we'd only have to add a small amount of randomness (perhaps even configurable) to an {{IpAddress}}. Currently, {{IpAddress}} uses 20 bytes in memory (JOL) and loses 4 due to mapping, so we could use 12 bytes for randomness.
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2080:
--------------------------------
Hmm... we could also start from the end and add 'randomness' to an {{IpAddress}}; rather than encoding the IP address and port in the UUID, we could add a 16 byte (or smaller) UUID to {{IpAddress}}.
The reason we abaondoned IpAddress a long time ago is that - if the port was fixed - we could run into _reincarnation issues_: a member with address {{192.168.1.3:5000}} crashing and immediately restarting would have the same address {{192.168.1.3:5000}} but still have state from old members (e.g. in {{NAKACK2}}).
Since the combination of IP address and port is pretty unique, we'd only have to add a small amount of randomness (perhaps even configurable) to an {{IpAddress}}. Currently, {{IpAddress}} uses 20 bytes in memory (JOL) and loses 4 due to mapping, so we could use 12 bytes for randomness.
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2062.
----------------------------
Resolution: Done
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2062
> URL: https://issues.jboss.org/browse/JGRP-2062
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {code:java}
> case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();
> {code}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2062:
---------------------------
Fix Version/s: 3.6.11
Backported to the 3.6 branch as well. Will break binary compatibilty if someone uses 3.6.10 and 3.6.11 in the same cluster and uses {{Util.objectToByteBuffer()}} methods.
However, the recommendation is to let users do their own serialization anyway, so this is fine IMO.
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2062
> URL: https://issues.jboss.org/browse/JGRP-2062
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {code:java}
> case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();
> {code}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months