[JBoss JIRA] (WFCORE-2796) CLI - module add - handle symlinks for directories and files
by Rostislav Svoboda (JIRA)
Rostislav Svoboda created WFCORE-2796:
-----------------------------------------
Summary: CLI - module add - handle symlinks for directories and files
Key: WFCORE-2796
URL: https://issues.jboss.org/browse/WFCORE-2796
Project: WildFly Core
Issue Type: Enhancement
Components: CLI
Reporter: Rostislav Svoboda
With WFCORE-2765 changes one can copy directories using CLI operation {{module add}}
I tried few non-empty directory cases
a) non-empty directory + subdirectories
b) non-empty directory + subdirectories + symlink (ln -s) to file (pom.xml -> /home/rsvoboda/tmp/wildfly-core/pom.xml)
c) non-empty directory + subdirectories + symlink (ln -s) to directory (jdk -> /opt/jdk1.8.0_91)
a) worked without problem
b) modules contain file (pom.xml) with copied content of sym-linked file, symlink not preserved
c) modules contain empty file jdk, content of sym-linked directory is not copied, symlink not preserved
Symlinks must be also handled, I would prefer to copy all the linked content to be consistent on different machines.
This can be complex as symlinks to files and directories can be nested in the directories structure.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2796) CLI - module add - handle symlinks for directories and files
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2796?page=com.atlassian.jira.plugi... ]
Rostislav Svoboda reassigned WFCORE-2796:
-----------------------------------------
Assignee: Jean-Francois Denise
> CLI - module add - handle symlinks for directories and files
> ------------------------------------------------------------
>
> Key: WFCORE-2796
> URL: https://issues.jboss.org/browse/WFCORE-2796
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Rostislav Svoboda
> Assignee: Jean-Francois Denise
>
> With WFCORE-2765 changes one can copy directories using CLI operation {{module add}}
> I tried few non-empty directory cases
> a) non-empty directory + subdirectories
> b) non-empty directory + subdirectories + symlink (ln -s) to file (pom.xml -> /home/rsvoboda/tmp/wildfly-core/pom.xml)
> c) non-empty directory + subdirectories + symlink (ln -s) to directory (jdk -> /opt/jdk1.8.0_91)
> a) worked without problem
> b) modules contain file (pom.xml) with copied content of sym-linked file, symlink not preserved
> c) modules contain empty file jdk, content of sym-linked directory is not copied, symlink not preserved
> Symlinks must be also handled, I would prefer to copy all the linked content to be consistent on different machines.
> This can be complex as symlinks to files and directories can be nested in the directories structure.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2167) Highest seqno is not resent nor recorded on receivers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2167?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2167 at 5/11/17 4:58 AM:
---------------------------------------------------------
OK, I added unit test {{LastMessageDroppedTest.testLastMessageAndLastSeqnoDropped()}} with {{STABLE.desired_avg_gossip_time}} set to 3000. This passes fine.
The test drops msg #3 out of 3 messages, and also drops the subsequent LAST_SEQNO (HIGHEST_SEQNO) message. However, STABLE kicks in and fixes this. The time range is {{\[0 .. avg_desired_gossip_time*2\]}}, so in the above test the max is ~6 seconds.
If you want, we can add another fixed time interval {{stable_interval}} which would send at fixed time (not random times within a range), to make this more predictable. This would (if set) override {{avg_desired_gossip_time}}.
Note that STABLE messages are sent _unreliably_, so if a STABLE message is dropped, we have to wait for the next round to get stability.
was (Author: belaban):
OK, I added unit test {{LastMessageDroppedTest.testLastMessageAndLastSeqnoDropped()}} with {{STABLE.desired_avg_gossip_time}} set to 3000.
The test drops msg #3 out of 3 messages, and also drops the subsequent LAST_SEQNO (HIGHEST_SEQNO) message. However, STABLE kicks in and fixes this. The time range is {{\[0 .. avg_desired_gossip_time*2\]}}, so in the above test the max is ~6 seconds.
If you want, we can add another fixed time interval {{stable_interval}} which would send at fixed time (not random times within a range), to make this more predictable. This would (if set) override {{avg_desired_gossip_time}}.
Note that STABLE messages are sent _unreliably_, so if a STABLE message is dropped, we have to wait for the next round to get stability.
> Highest seqno is not resent nor recorded on receivers
> -----------------------------------------------------
>
> Key: JGRP-2167
> URL: https://issues.jboss.org/browse/JGRP-2167
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.4
>
>
> I am investigating an issue in a stress test which leads me to a situation where in a TCP-based configuration a {{GMS[VIEW]}} is broadcast to all nodes, but it is not received by some of them. Soon after that there's a {{NAKACK2.HIGHEST_SEQNO}} that causes the node that is missing the last seqno to resend it, but the retransmit is not received either. There are no further retries, and generally no NAKACK2 activity until about 30 seconds later (when another node leaves after some timeout in the test).
> The receiver does not keep asking for retransmissions until it gets them, but it seems that {{NAKACK2.handleHighestSeqno}} doesn't update {{Table.hr}} (not sure if having highest received set to non-received msg would be legal, though).
> The sender uses default value {{NAKACK2.resend_last_seqno_max_times=1}}, and as there are no further mcast messages, the highest sent seqno does not change on sender.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2167) Highest seqno is not resent nor recorded on receivers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2167?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2167:
--------------------------------
OK, I added unit test {{LastMessageDroppedTest.testLastMessageAndLastSeqnoDropped()}} with {{STABLE.desired_avg_gossip_time}} set to 3000.
The test drops msg #3 out of 3 messages, and also drops the subsequent LAST_SEQNO (HIGHEST_SEQNO) message. However, STABLE kicks in and fixes this. The time range is {{\[0 .. avg_desired_gossip_time*2\]}}, so in the above test the max is ~6 seconds.
If you want, we can add another fixed time interval {{stable_interval}} which would send at fixed time (not random times within a range), to make this more predictable. This would (if set) override {{avg_desired_gossip_time}}.
Note that STABLE messages are sent _unreliably_, so if a STABLE message is dropped, we have to wait for the next round to get stability.
> Highest seqno is not resent nor recorded on receivers
> -----------------------------------------------------
>
> Key: JGRP-2167
> URL: https://issues.jboss.org/browse/JGRP-2167
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.4
>
>
> I am investigating an issue in a stress test which leads me to a situation where in a TCP-based configuration a {{GMS[VIEW]}} is broadcast to all nodes, but it is not received by some of them. Soon after that there's a {{NAKACK2.HIGHEST_SEQNO}} that causes the node that is missing the last seqno to resend it, but the retransmit is not received either. There are no further retries, and generally no NAKACK2 activity until about 30 seconds later (when another node leaves after some timeout in the test).
> The receiver does not keep asking for retransmissions until it gets them, but it seems that {{NAKACK2.handleHighestSeqno}} doesn't update {{Table.hr}} (not sure if having highest received set to non-received msg would be legal, though).
> The sender uses default value {{NAKACK2.resend_last_seqno_max_times=1}}, and as there are no further mcast messages, the highest sent seqno does not change on sender.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2392) Remoting EJB identity propagation does not work with Elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2392?page=com.atlassian.jira.plugi... ]
Jan Kalina commented on WFCORE-2392:
------------------------------------
^^ Resolved by adding *FORM* mechanism configuration into *EjbElytronDomainSetup*.
> Remoting EJB identity propagation does not work with Elytron
> ------------------------------------------------------------
>
> Key: WFCORE-2392
> URL: https://issues.jboss.org/browse/WFCORE-2392
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Labels: elytron-legacy-test-fails
> Fix For: 3.0.0.Beta18
>
>
> Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
> Identity is unauthorized on server side.
> *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference.
> Often error message:
> {code:java}
> SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: Server rejected authentication
> DIGEST-MD5: Server rejected authentication]
> at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2167) Highest seqno is not resent nor recorded on receivers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2167?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2167:
--------------------------------
I'll add a new test to (existing) {{LastMessageDroppedTest}}
> Highest seqno is not resent nor recorded on receivers
> -----------------------------------------------------
>
> Key: JGRP-2167
> URL: https://issues.jboss.org/browse/JGRP-2167
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.4
>
>
> I am investigating an issue in a stress test which leads me to a situation where in a TCP-based configuration a {{GMS[VIEW]}} is broadcast to all nodes, but it is not received by some of them. Soon after that there's a {{NAKACK2.HIGHEST_SEQNO}} that causes the node that is missing the last seqno to resend it, but the retransmit is not received either. There are no further retries, and generally no NAKACK2 activity until about 30 seconds later (when another node leaves after some timeout in the test).
> The receiver does not keep asking for retransmissions until it gets them, but it seems that {{NAKACK2.handleHighestSeqno}} doesn't update {{Table.hr}} (not sure if having highest received set to non-received msg would be legal, though).
> The sender uses default value {{NAKACK2.resend_last_seqno_max_times=1}}, and as there are no further mcast messages, the highest sent seqno does not change on sender.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (HAWKULARQE-71) Test Hawkular Java Agent
by Hayk Hovsepyan (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-71?page=com.atlassian.jira.plu... ]
Hayk Hovsepyan commented on HAWKULARQE-71:
------------------------------------------
Hawkular javaagent is for containers in downstream.
So when running EAP7 from brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss/jboss-eap-7-hawkular-agent, it comes with javaagent.
It just needs to be smoke tested that EAP7 container is recognized and metrics are collected.
> Test Hawkular Java Agent
> ------------------------
>
> Key: HAWKULARQE-71
> URL: https://issues.jboss.org/browse/HAWKULARQE-71
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Hayk Hovsepyan
> Assignee: Sunil kondkar
> Priority: Minor
>
> There is a new Java Agent (HJA) that you can run in any JVM (including
> but not limited to EAP-based projects). You do so by passing in a
> "-javaagent" command line option to your JVM (e.g. java
> -javaagent=hawkular-javaagent.jar=config=config.yaml -jar my-app.jar
> ...yadda...). There are two additional properties you must set in
> standalone.conf if you want to run it inside an EAP JVM. The README will
> have the details.
> This new HJA is configured with a yaml file that largely mimics all the
> standalone.xml data that HWFA has. There is no ${x} support in the YAML
> file right now.
> This new HJA can talk to any EAP or WildFly server over the DMR management
> API. It can do deployments to your EAP/WildFly servers and monitoring of
> EAP/WildFly subsystems just like HWFA can.
> This new HJA can talk to any JMX server just like HWFA can (it will talk to
> the local MBeanServer or, if remotely monitoring a JMX server, it will talk
> to it over Jolokia/REST API).
> This new HJA can NOT run directly inside of a Host Controller due to
> https://issues.jboss.org/browse/WFCORE-2526 - however, you can run HJA
> externally in its own JVM (e.g. java -jar hawkular-javaagent.jar
> config=config.yaml) and have its config.yaml point to a remote Host
> Controller and you'll get the same functionality.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2167) Highest seqno is not resent nor recorded on receivers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2167?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2167:
--------------------------------
I'll write a unit test that drops the last multicast message to a member, plus the accompanying LAST_SEQNO mesage: STABLE with a timeout of 5 should resolve this within ~5 seconds.
And no, STABLE doesn't adjust {{desired_avg_gossip_time}} based on cluster size / ergonomics anymore (this was indeed the case some time ago).
> Highest seqno is not resent nor recorded on receivers
> -----------------------------------------------------
>
> Key: JGRP-2167
> URL: https://issues.jboss.org/browse/JGRP-2167
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.4
>
>
> I am investigating an issue in a stress test which leads me to a situation where in a TCP-based configuration a {{GMS[VIEW]}} is broadcast to all nodes, but it is not received by some of them. Soon after that there's a {{NAKACK2.HIGHEST_SEQNO}} that causes the node that is missing the last seqno to resend it, but the retransmit is not received either. There are no further retries, and generally no NAKACK2 activity until about 30 seconds later (when another node leaves after some timeout in the test).
> The receiver does not keep asking for retransmissions until it gets them, but it seems that {{NAKACK2.handleHighestSeqno}} doesn't update {{Table.hr}} (not sure if having highest received set to non-received msg would be legal, though).
> The sender uses default value {{NAKACK2.resend_last_seqno_max_times=1}}, and as there are no further mcast messages, the highest sent seqno does not change on sender.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2795) Writing invalid value for cipher-suite-filter attribute of Elytron *-ssl-context should result in failure
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2795?page=com.atlassian.jira.plugi... ]
Yeray Borges moved JBEAP-10851 to WFCORE-2795:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2795 (was: JBEAP-10851)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
(was: User Experience)
Affects Version/s: (was: 7.1.0.DR8)
> Writing invalid value for cipher-suite-filter attribute of Elytron *-ssl-context should result in failure
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2795
> URL: https://issues.jboss.org/browse/WFCORE-2795
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Labels: cipher-suite, error_handling, ssl, user_experience, validation
>
> Writing invalid value for {{cipher-suite-filter}} attribute of {{*-ssl-context}} results in {{"outcome" => "success"}} and requires reload. After reload there are errors in server log, but there is no notice in CLI. A user should be notified immediately that entered value is not correct -- the operation should fail.
> Furthermore, when an invalid combination of {{cipher-suite-filter}} and {{protocols}} is entered, the operation passes and there are errors in server log after reload only. Again, a user should be notified immediately that entered combination of values is not correct -- the operation should fail. Should I create separate JIRA issue for this?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2162 at 5/11/17 4:07 AM:
---------------------------------------------------------
3. I never recommend TCPPING, except when other (more dynamic) discovery protocols cannot be used. If TCPPING is to be used, I always recommend to list all members.
Re set {{send_cache_on_join}} to true by default: hmm, this increases traffic on joins... The default value would have to be set in superclass {{Discovery}}, and that's not something I want to do, as most discovery protocols are dynamic.
I also don't want to override this attribute in TCPPING as I don't like silently changing attributes.
Why don't you set either {{send_cache_on_join}} or {{return_entire_cache}} in the Infinispan configuration to true by default instead?
was (Author: belaban):
3. I never recommend TCPPING, except when other (more dynamic) discovery protocols cannot be used. If TCPPING is to be used, I always recommend to list all members.
Re set {{send_cache_on_join}} to true by default: hmm, this increases traffic on joins... OK, I'll change this for TCPPING only for now...
> Failed to send broadcast when opening the connection
> ----------------------------------------------------
>
> Key: JGRP-2162
> URL: https://issues.jboss.org/browse/JGRP-2162
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 4.0.4
>
> Attachments: TcpNio2McastTest.java, infinispan_2.log.gz
>
>
> IRC discussion:
> {quote}
> bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
> <bela_> rvansa: reproducible?
> <rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
> <rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
> <bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
> <bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
> <rvansa> bela_: I don't think it should go over the limit
> <rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
> <rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
> {quote}
> I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]):
> {code:xml}
> <TCPPING async_discovery="true" initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800]}" port_range="0"/>
> {code}
> This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore).
> Note that increasing the timeout in request options does not help.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months