[JBoss JIRA] (JGRP-2236) UNICAST max_xmit_req_size doesn't work
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2236?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2236:
--------------------------------
Seems to me that a quick workaround is to manually set {{max_xmit_req_size}} (default: 0)...
> UNICAST max_xmit_req_size doesn't work
> --------------------------------------
>
> Key: JGRP-2236
> URL: https://issues.jboss.org/browse/JGRP-2236
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Fix For: 4.0.9
>
>
> UNICAST3 sets max_xmit_req_size to avoid requesting too many messages to fit into the maximum message size.
> But the check is implemented incorrectly, so it is not effective.
> JGRP000029: node1: failed sending message to node2 (120314 bytes): java.io.IOException: Message too long, headers: UNICAST3: XMIT_REQ, seqno=0, TP: [cluster_name=cluster]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9574) Distribution files does not have POSIX permissions perfectly set
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9574?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9574:
----------------------------------------
Please discuss this on the wildfly-dev list.
> Distribution files does not have POSIX permissions perfectly set
> ----------------------------------------------------------------
>
> Key: WFLY-9574
> URL: https://issues.jboss.org/browse/WFLY-9574
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System
> Affects Versions: 11.0.0.Final
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
>
> The server provisioning copy (and extract) files in order to assemble the distribution based the information of the feature-pack. While doing so on a POSIX system, it keeps the permissions of the original files, which are not always optimum (see JBEAP-12374). For instance:
> * .properties and .jar files are associated with the mask rw-rw-r-- giving access to it to any other and allowing group member to modify the file ;
> * some directories like domain/tmp/auth have to restrictive mask like rwx------ that needs to be turned into rwxrwxr-x and other, likes domain have again a too permissive mask rwxrwxr-x (should be rwxr-xr-x).
> On a "regular" Maven project, all of those changes could be specified in the assembly.xml, however in Wildfly cases, this is not really option because the provisioning-maven-plugin and feature-pack-build-maven-plugin are manipulating the content of the archive being built. Also, using assembly.xml would mean edit and update the 4 or 5 different assembly.xml in the project directory tree.
> I plan thus to propose a fix for wildfly-build-tools to address all those (small) problems.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (JGRP-2236) UNICAST max_xmit_req_size doesn't work
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2236?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2236:
--------------------------------
OK, I taking a look at it...
> UNICAST max_xmit_req_size doesn't work
> --------------------------------------
>
> Key: JGRP-2236
> URL: https://issues.jboss.org/browse/JGRP-2236
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Fix For: 4.0.9
>
>
> UNICAST3 sets max_xmit_req_size to avoid requesting too many messages to fit into the maximum message size.
> But the check is implemented incorrectly, so it is not effective.
> JGRP000029: node1: failed sending message to node2 (120314 bytes): java.io.IOException: Message too long, headers: UNICAST3: XMIT_REQ, seqno=0, TP: [cluster_name=cluster]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3431) Embedded wildfly server does not combine with the latest logback version.
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created WFCORE-3431:
----------------------------------------
Summary: Embedded wildfly server does not combine with the latest logback version.
Key: WFCORE-3431
URL: https://issues.jboss.org/browse/WFCORE-3431
Project: WildFly Core
Issue Type: Bug
Components: Server
Reporter: Geoffrey De Smet
Assignee: Jason Greene
Logback 1.2.3 doesn't combine with the embedded WildFly server. Older versions did.
The reason might be because Logback/slf4j now uses the JDK ServiceLoader mechanism to find the logging implementation (mandetory as of java 9 in modulepaths), which uses META-INF files, which isn't that combinable with the way jboss modules was made to work in embeddable wildfly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on WFCORE-3205:
------------------------------------------
Excluding the jboss-logmanager depedency is *not a workaround*, but all system.out lines get prepended by a fixed logging format, so all lines contain the timestamp twice etc (once for the war's logger and once from the wrapping by wildfly system.out wrapper).
> Logging does not work in the embedded server
> --------------------------------------------
>
> Key: WFCORE-3205
> URL: https://issues.jboss.org/browse/WFCORE-3205
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet edited comment on WFCORE-3205 at 11/27/17 9:20 AM:
--------------------------------------------------------------------
Excluding the jboss-logmanager depedency is *not a workaround*, because all system.out lines get prepended by a fixed logging format, so all lines contain the timestamp twice etc (once for the war's logger and once from the wrapping by wildfly system.out wrapper).
was (Author: ge0ffrey):
Excluding the jboss-logmanager depedency is *not a workaround*, but all system.out lines get prepended by a fixed logging format, so all lines contain the timestamp twice etc (once for the war's logger and once from the wrapping by wildfly system.out wrapper).
> Logging does not work in the embedded server
> --------------------------------------------
>
> Key: WFCORE-3205
> URL: https://issues.jboss.org/browse/WFCORE-3205
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ELY-1422) Add possibility to disable channel binding in Elytron clients
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1422?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1422:
---------------------------------
as discussed in JBEAP-12894, there is no reason to allow using non-PLUS mechanism with TLS, this will be closed.
> Add possibility to disable channel binding in Elytron clients
> -------------------------------------------------------------
>
> Key: ELY-1422
> URL: https://issues.jboss.org/browse/ELY-1422
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Affects Versions: 1.2.0.Beta7
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Add Elytron client option to disable channel binding so non-PLUS (SCRAM) mechanisms can be used even if the SSL context is configured for the underlying remoting connection.
> This is a follow up jira to JBEAP-12231 (and transitively JBEAP-11396) - look for full discussion there.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months