[JBoss JIRA] (WFLY-13887) Add http-connections element to jboss-ejb-client_1_4.xsd schema
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13887?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13887:
-----------------------------------
Thanks [~sudeshnas] for resolving this issue.
> Add http-connections element to jboss-ejb-client_1_4.xsd schema
> ---------------------------------------------------------------
>
> Key: WFLY-13887
> URL: https://issues.redhat.com/browse/WFLY-13887
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Sudeshna Sur
> Priority: Major
> Fix For: 21.0.0.Final
>
>
> Need to add the new element to jboss-ejb-client_1_4.xsd schema:
> {code:xml}
> <jboss-ejb-client xmlns="urn:jboss:ejb-client:1.4">
> <client-context default-compression="-1">
> <http-connections>
> <http-connection uri="http://localhost:8180/wildfly-services"/>
> </http-connections>
> </client-context>
> </jboss-ejb-client>
> {code}
> Also need to update jboss-ejb-client.adoc to reflect the new element.
> This element (http-connections) is already implemented as part of WFLY-12190 EJB over HTTP discovery configuration.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFCORE-605) MORE_JAVA_OPTS for standalone.sh
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-605?page=com.atlassian.jira.plugi... ]
James Perkins closed WFCORE-605.
--------------------------------
Resolution: Won't Do
There are likely several workarounds for this so unless it's still an issue I suggest we close this. Please feel free to reopen if this is something that should be looked at.
> MORE_JAVA_OPTS for standalone.sh
> --------------------------------
>
> Key: WFCORE-605
> URL: https://issues.redhat.com/browse/WFCORE-605
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Scripts
> Reporter: Arun Gupta
> Priority: Major
>
> Extend standalone.sh such that it takes an additional environment variable that is then added to JAVA_OPTS during startup.
> This can be used for passing additional Java options from WildFly
> Docker image. Cursory look at the script does not reveal anything like
> that exist.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFCORE-408) Add a TRACE level category for the operations used to start a server.
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-408?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-408:
--------------------------------------
[~dlofthouse] This was created a while ago. Do you recall the intent here? I'm pretty sure ops can be logged at boot time.
> Add a TRACE level category for the operations used to start a server.
> ---------------------------------------------------------------------
>
> Key: WFCORE-408
> URL: https://issues.redhat.com/browse/WFCORE-408
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Logging, Management
> Reporter: Darran Lofthouse
> Priority: Major
>
> Sometimes after being able to start a server from the XML configuration it is useful to be able to identify the actual operations that are executed to start the server.
> From a development perspective this is useful for double checking the operations are as we expect.
> From an end user perspective this can be useful to identify the set of equivalent operations needed if the same was to be achieved in a CLI script.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFCORE-4518) Ensure the ServiceTarget is stable for the subsystem test KernelServices
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-4518?page=com.atlassian.jira.plug... ]
James Perkins closed WFCORE-4518.
---------------------------------
Resolution: Out of Date
This seems to not longer be an issue.
> Ensure the ServiceTarget is stable for the subsystem test KernelServices
> ------------------------------------------------------------------------
>
> Key: WFCORE-4518
> URL: https://issues.redhat.com/browse/WFCORE-4518
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> There is potential that an operation is executed for a runtime resource in the subsystem tests if the {{ServiceTarget}} is not yet stable. Using a {{StabilityMonitor}} should fix this issue.
> Example stack trace when a test fails
> {code}
> org.jboss.as.controller.OperationFailedException: undefined [ undefined ]
> at org.jboss.as.model.test.ModelTestKernelServicesImpl.executeForResult(ModelTestKernelServicesImpl.java:238)
> at org.jboss.as.remoting.RemotingSubsystemTestCase.testEndpointConfigurationViaSubsystemRoot(RemotingSubsystemTestCase.java:258)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFCORE-4845) Allow Remote Debug Connections on Java 9+ With StandaloneCommandBuilder
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-4845?page=com.atlassian.jira.plug... ]
James Perkins commented on WFCORE-4845:
---------------------------------------
I'm debating if we want to do this or not. The simple solution is to just do {{StandaloneCommandBuilder.addJavaOption("-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005")}}. We don't, and I don't think we should, support this in the standalone scripts. This would make the launcher API behave differently.
> Allow Remote Debug Connections on Java 9+ With StandaloneCommandBuilder
> -----------------------------------------------------------------------
>
> Key: WFCORE-4845
> URL: https://issues.redhat.com/browse/WFCORE-4845
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Launcher
> Reporter: Josh Fisher
> Assignee: James Perkins
> Priority: Minor
>
> When using StandaloneCommandBuilder#setDebug method to set the debug VM argument it will use this format:
> -agentlib:jdwp=transport=dt_socket,server=y,suspend=$suspend,address=$debugPort
> On Java 9+, this will only accept connections from the localhost, while in Java 8 this will accept connections from any host. It is possible to support remote connections on Java 9+ by configuring the argument in the Java options list instead of using setDebug as a workaround.
> While debug connections from remote hosts are not especially common, there are some use cases where it may be desired. For consistency between Java versions, we should consider using the wildcard "*" host so the debug argument format is:
> -agentlib:jdwp=transport=dt_socket,server=y,suspend=$suspend,address=*:$debugPort
>
> I believe one way this could be achieved is by modifying the DEBUG_FORMAT to:
> DEBUG_FORMAT = "-agentlib:jdwp=transport=dt_socket,server=y,suspend=%s,address=%s"
> then in setDebug check the environment VM and format the address accordingly.
> {code:java}
> public StandaloneCommandBuilder setDebug(boolean suspend, int port) {
> final String address;
> if (environment.getJvm().isModular()){
> address = "*:" + port;
> } else {
> address = String.valueOf(port);
> }
> debugArg = String.format(DEBUG_FORMAT, (suspend ? "y" : "n"), address);
> return this;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFCORE-4845) Allow Remote Debug Connections on Java 9+ With StandaloneCommandBuilder
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-4845?page=com.atlassian.jira.plug... ]
James Perkins reassigned WFCORE-4845:
-------------------------------------
Assignee: James Perkins (was: Katarína Hermanová)
> Allow Remote Debug Connections on Java 9+ With StandaloneCommandBuilder
> -----------------------------------------------------------------------
>
> Key: WFCORE-4845
> URL: https://issues.redhat.com/browse/WFCORE-4845
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Launcher
> Reporter: Josh Fisher
> Assignee: James Perkins
> Priority: Minor
>
> When using StandaloneCommandBuilder#setDebug method to set the debug VM argument it will use this format:
> -agentlib:jdwp=transport=dt_socket,server=y,suspend=$suspend,address=$debugPort
> On Java 9+, this will only accept connections from the localhost, while in Java 8 this will accept connections from any host. It is possible to support remote connections on Java 9+ by configuring the argument in the Java options list instead of using setDebug as a workaround.
> While debug connections from remote hosts are not especially common, there are some use cases where it may be desired. For consistency between Java versions, we should consider using the wildcard "*" host so the debug argument format is:
> -agentlib:jdwp=transport=dt_socket,server=y,suspend=$suspend,address=*:$debugPort
>
> I believe one way this could be achieved is by modifying the DEBUG_FORMAT to:
> DEBUG_FORMAT = "-agentlib:jdwp=transport=dt_socket,server=y,suspend=%s,address=%s"
> then in setDebug check the environment VM and format the address accordingly.
> {code:java}
> public StandaloneCommandBuilder setDebug(boolean suspend, int port) {
> final String address;
> if (environment.getJvm().isModular()){
> address = "*:" + port;
> } else {
> address = String.valueOf(port);
> }
> debugArg = String.format(DEBUG_FORMAT, (suspend ? "y" : "n"), address);
> return this;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Andrew Skalski (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Andrew Skalski commented on JGRP-2504:
--------------------------------------
net.core.rmem_max is the limit on how large of a SO_RCVBUF an application may request. If the application attempts to request a larger buffer, it is clamped to the value specified in net.core.rmem_max.
Buffer size and window size are related but distinct. The buffer size is how much kernel memory is allocated to the socket; the receive window (a number advertised in the TCP header, indicating how much more data it is willing to receive at a given moment in time) depends on the buffer size and other factors.
Setting SO_SNDBUF on a listening socket works without issue in C. Here is strace output of the "iperf3" utility setting up its listening socket with a requested buffer size of 123456. The setsockopt calls all return 0 (success):
{code:java}
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [123456], 4) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [123456], 4) = 0
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0
bind(3, {sa_family=AF_INET6, sin6_port=htons(7800), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0
listen(3, 5) = 0
{code}
But based on what I've been able to piece together, it's completely OK – at least with Linux – to wait until after accepting a connection to configure SO_SNDBUF. Considering that Java's ServerSocket lacks a setSendBufferSize method, I think it's safe to assume that it's OK on other platforms as well.
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java, bla6.java, bla7.java, delay-ip.sh, rcvbuf.png
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2504:
--------------------------------
OK, so this means setting SO_RCVBUF replaces {{net.core.rmem_max}}? And the initial buffer size is the default size set in {{sysctl.conf}}?
Speaking of buffers: I assume buffer size == TCP recv/send window size?
Last point: setting SO_SNDBUF on a server socket in Java is not supported:
{{srv_sock.setOption(StandardSocketOptions.SO_RCVBUF, receive_buf_size)}} throws an exception. I haven't been in C land for quite a while, but do you know if this is supported in C?
Cheers,
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java, bla6.java, bla7.java, delay-ip.sh, rcvbuf.png
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months