[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 commented on JGRP-2162:
--------------------------------
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
[JBoss JIRA] (WFCORE-2768) There is ConcurrentModificationException when we write new aliases to one credential store resource through multiple threads (management clients)
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2768?page=com.atlassian.jira.plugi... ]
Yeray Borges commented on WFCORE-2768:
--------------------------------------
The issue has been discussed getting following conclusions:
* The use of context.getServiceRegistry(true) is to prevent concurrent management writes, since this issue is related to how internal structures of CredentialStore are being managed concurrently, we must use a different approach to avoid the concurrency problems.
* Credential store aliases are going to be exposed as operations instead of resources in WFCORE-2777, so maybe this issue is fixed due to that change. Once WFCORE-2777 will be merged, we will test aginst new code to check if we can hit the bug again.
* Anyway since CredentialStore service is modifying internal data, it must be retrieved with getServiceRegistry(true)
> There is ConcurrentModificationException when we write new aliases to one credential store resource through multiple threads (management clients)
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2768
> URL: https://issues.jboss.org/browse/WFCORE-2768
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Yeray Borges
> Priority: Critical
>
> There is ConcurrentModificationException when
> we write new aliases to one credential store resource through multiple threads (management clients)
> *Use case:*
> More users are connected through CLI to same application server and work parallel with same credential store resource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1087) Elytron caching-realm backed by ldap-realm should evict or update the cache when a related role changes in LDAP
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1087?page=com.atlassian.jira.plugin.s... ]
Jan Kalina closed ELY-1087.
---------------------------
Resolution: Rejected
Modification listening for attributes filtered from different entities is not supported, same as their modification.
> Elytron caching-realm backed by ldap-realm should evict or update the cache when a related role changes in LDAP
> ---------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1087
> URL: https://issues.jboss.org/browse/ELY-1087
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta37
> Environment: LDAP: ApacheDS
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: caching, eap71_beta, ldap, ldap-realm, security-realm
>
> Elytron {{caching-realm}} backed by {{ldap-realm}} does not evict or update a cached identity when a role related to the identity is changed in LDAP, see steps to reproduce.
> This is against the following hard requirement of EAP7-542: _"Ability to listen for events fired by a modifiable realm in order to evict or update the cache accordingly."_ The ability is available but not used in this case. Hence the priority is set to {{Blocker}}. The issue blocks the RFE to be verified. The issue does not block test development for the RFE. The issue has been revealed by fixing JBEAP-8679.
> The eviction/updating works when user password is changed in LDAP.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1125) WildFly Elytron Tool, Omitting --location for Vault command leads to wrong credential store storage file in tool output and in summary output.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1125?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek commented on ELY-1125:
-----------------------------------
[~ivassile]
Yes it's correct.
> WildFly Elytron Tool, Omitting --location for Vault command leads to wrong credential store storage file in tool output and in summary output.
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1125
> URL: https://issues.jboss.org/browse/ELY-1125
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> Omitting --location for Vault command leads to wrong credential store storage file in tool output and in summary output.
> In this case when is omitted --location
> * tool output contains credential store storage file name with "enc-dir" path prefix.
> * summary output contains in location double slash in case of enc-dir value ends by slash
> *Expected behaviour:*
> Tool output must show only storage file name.
> Summary output must not contain double slash in location
> *How to reproduce*
> Download all attachments to same location as wildfly-elytron-tool.jar
> option --location must be omitted, --enc-dir must end by slash.
> {code}
> [hsvabek@dhcp-10-40-5-100 003]$ java -jar wildfly-elytron-tool.jar vault --enc-dir ./ --keystore server.store --keystore-password secretsecret --alias jboss -f
> Vault (enc-dir="./";keystore="server.store") converted to credential store ".//converted-vault.cr-store"
> Vault Conversion summary:
> --------------------------------------
> Vault Conversion Successful
> CLI command to add new credential store:
> /subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location=".//converted-vault.cr-store",implementation-properties={},credential-reference={clear-text="MASK-13KrO2ZNhwNg3UxmIt.02D;12345678;23"})
> {code}
> Now you can see *".//converted-vault.cr-store"* on tool output right value is *"converted-vault.cr-store"*
> and location=*".//converted-vault.cr-store"* in summary output for which is correct value *"./converted-vault.cr-store"*.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (LOGMGR-156) Add a SocketHandler
by James Perkins (JIRA)
James Perkins created LOGMGR-156:
------------------------------------
Summary: Add a SocketHandler
Key: LOGMGR-156
URL: https://issues.jboss.org/browse/LOGMGR-156
Project: JBoss Log Manager
Issue Type: Feature Request
Reporter: James Perkins
Assignee: James Perkins
A socket handler should be added so that log records can be sent over generic sockets. This will be helpful for [JSON and XML|LOGMGR-155] formats.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (LOGMGR-155) Add JSON and XML formatters
by James Perkins (JIRA)
James Perkins created LOGMGR-155:
------------------------------------
Summary: Add JSON and XML formatters
Key: LOGMGR-155
URL: https://issues.jboss.org/browse/LOGMGR-155
Project: JBoss Log Manager
Issue Type: Feature Request
Reporter: James Perkins
Assignee: James Perkins
Add formatters which can format log messages in JSON and XML. These could be useful for log aggregators.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8409) Backward compatibility: IIOP doesn't work with standalone-full profile from EAP 7.0.0
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-8409?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski closed WFLY-8409.
--------------------------------
> Backward compatibility: IIOP doesn't work with standalone-full profile from EAP 7.0.0
> -------------------------------------------------------------------------------------
>
> Key: WFLY-8409
> URL: https://issues.jboss.org/browse/WFLY-8409
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 10.1.0.Final
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Priority: Blocker
> Fix For: 11.0.0.Beta1
>
>
> *Description of problem:*
> IIOP doesn't work with standalone-full profile from EAP 7.0.0.
> This is regression against EAP 7.1.0.DR10.
> This backward compatibility works correctly in EAP 6.x. EAP 6.4.0 works correctly with standalone-full.xml from EAP 6.0.0.
> {code:diff}
> @@ -270,8 +271,9 @@
> </cache-container>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:iiop-openjdk:3.0">
> - <orb socket-binding="iiop" ssl-socket-binding="iiop-ssl"/>
> + <orb socket-binding="iiop"/>
> <initializers security="identity" transactions="spec"/>
> + <security server-requires-ssl="false" client-requires-ssl="false"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:jaxrs:1.0"/>
> <subsystem xmlns="urn:jboss:domain:jca:4.0">
> @@ -304,7 +306,7 @@
> {code}
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # get fresh EAP 7.1.0.DR11
> # rm standalone/configuration/standalone-full.xml
> # cp $\{EAP_7_0_0\}/standalone/configuration/standalone-full.xml standalone/configuration/
> # ./bin/standalone.sh -c standalone-full.xml
> *Actual results:*
> {noformat}
> ...
> 10:43:53,503 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 42) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "iiop-openjdk")]) - failure description: "WFLYIIOP0111: SSL has not been configured but ssl-port property has been specified"
> 10:43:53,515 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 42) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "iiop-openjdk")]) - failure description: "WFLYIIOP0111: SSL has not been configured but ssl-port property has been specified"
> ...
> 10:43:55,251 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha22-redhat-1) started in 3272ms - Started 385 of 615 services (419 services are lazy, passive or on-demand)
> {noformat}
> *Expected results:*
> No error on output.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8748) CONSOLE handler in Domain "full-ha" profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-8748?page=com.atlassian.jira.plugin.... ]
James Perkins moved JBEAP-10849 to WFLY-8748:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8748 (was: JBEAP-10849)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
Logging
(was: Domain Management)
(was: Logging)
(was: Performance)
Affects Version/s: (was: 7.0.z.GA)
> CONSOLE handler in Domain "full-ha" profile
> -------------------------------------------
>
> Key: WFLY-8748
> URL: https://issues.jboss.org/browse/WFLY-8748
> Project: WildFly
> Issue Type: Task
> Components: Domain Management, Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> In EAP 7 console-handler was disabled by default in standalone-full-ha.xml because this profile is intended for production use. But "full-ha" profile in domain.xml contain the CONSOLE handler, by the same reasoning, it should not be there.
> Logging subsystem configuration in domain.xml "full-ha" profile :
> {code}
> <profile name="full-ha">
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> <periodic-rotating-file-handler name="FILE" autoflush="true">
> <formatter>
> <named-formatter name="PATTERN"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="server.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="true"/>
> </periodic-rotating-file-handler>
> <logger category="com.arjuna">
> <level name="WARN"/>
> </logger>
> <logger category="org.jboss.as.config">
> <level name="DEBUG"/>
> </logger>
> <logger category="sun.rmi">
> <level name="WARN"/>
> </logger>
> <root-logger>
> <level name="INFO"/>
> <handlers>
> <handler name="CONSOLE"/>
> <handler name="FILE"/>
> </handlers>
> </root-logger>
> <formatter name="PATTERN">
> <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> </subsystem>
> ....
> </profile>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months