[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1145:
------------------------------------------
I incorrectly asked this on WFCORE-1147.
"If there is a return channel, why would we get stdin involved?"
My question was specifically in reference to how this helps with WFCORE-1135, since the return channel connected to an ephemeral socket is AFAIK the same basic thing as we already have. I can certainly see using on the HC a different socket from the externally accessible one and only allowing it to be bound to localhost would be helpful.
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha1
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1147) Eliminate ProcessController
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1147?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1147:
------------------------------------------
Sorry, I meant to paste that question on WFCORE-1145, not here.
This JIRA isn't really the best place to discuss HC/server communication for management op execution, since the PC is not involved. For the question of stdin vs socket, having a PC in the middle of the stdin path is just a detail. Of course if we were sending more over stdin that's another good reason to get rid of the PC, but there are already good reasons.
> Eliminate ProcessController
> ---------------------------
>
> Key: WFCORE-1147
> URL: https://issues.jboss.org/browse/WFCORE-1147
> Project: WildFly Core
> Issue Type: Task
> Components: Server
> Reporter: David Lloyd
>
> We should eliminate ProcessController and directly have the HC control the servers. This should greatly simplify the code and add more power and flexibility to the management and lifecycle of server JVMs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1155) DomainApiGenericOperationHandler doesn't handle auto-closing streams
by James Perkins (JIRA)
James Perkins created WFCORE-1155:
-------------------------------------
Summary: DomainApiGenericOperationHandler doesn't handle auto-closing streams
Key: WFCORE-1155
URL: https://issues.jboss.org/browse/WFCORE-1155
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: James Perkins
Assignee: James Perkins
The {{DomainApiGenericOperationHandler}} needs to ensure any input streams it attaches to an operation are closed. In the case of a content upload two streams are attached and only one is closed during the add of the content in the operation step handler.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-643) On Windows, setting the JAVA_OPTS variable is not
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-643?page=com.atlassian.jira.plugin... ]
Tomaz Cerar reassigned WFCORE-643:
----------------------------------
Assignee: (was: Tomaz Cerar)
> On Windows, setting the JAVA_OPTS variable is not
> -------------------------------------------------
>
> Key: WFCORE-643
> URL: https://issues.jboss.org/browse/WFCORE-643
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 1.0.0.Beta4
> Environment: Windows 7 x64, JRE was bundled with JDK 8 u40 x64.
> Hardware specs:
> CPU: Intel Core i7-3720QM CPU @ 2.60 GHz
> RAM: 16.0 GB
> GPU: NVIDIA Quadro K1000M
> Others upon request.
> Reporter: Tom Kelley
> Priority: Minor
>
> {warn} This issue was copy/pasted from a github issue [here|https://github.com/wildfly/wildfly/issues/7352]. I apologize for 1) the issue duplication, 2) the length of the issue, 3) any poor communication that the transcription caused. {warn}
> My company uses JBoss AS, and I have a copy on my local machine. In setting it up, I wrote a small script that lives in the bin directory and looks something like this:
> {code}
> @rem Delete current log file
> del /F /Q ..\standalone\log\server.log
> @rem Set Java Opts because I want to
> set JAVA_OPTS="-XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms1303M -Xmx1303M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -agentlib:jdwp=transport=dt_socket,server=y,suspend=n"
> @rem Set the new Java Home
> set JAVA_HOME=C:\bin\java\jdk8_u40_64\jre
> @rem Run Jboss
> standalone.bat -c=standalone-full.xml --debug
> {code}
> I noticed when I was starting the server that the JAVA_OPTS in the debug text were not what I was passing in. I figured I could get to the bottom of what was going on, so I started digging in. My investigation led me to standalone.conf.bat, which looks like this:
> {code}
> rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
> rem set PRESERVE_JAVA_OPTS=true
> if not "x%JAVA_OPTS%" == "x" (
> echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
> goto JAVA_OPTS_SET
> )
> {code}
> This is very interesting. This snippet of code appears to be a bug. As someone who has worked with batch files, I believe that the correct code should look like this:
> {code}
> rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
> rem set PRESERVE_JAVA_OPTS=true
> if not "x"%JAVA_OPTS% == "x" (
> echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
> goto JAVA_OPTS_SET
> )
> {code}
> You must be thinking, "if you know how to do this, why don't you just make the change yourself? It seems trivial." I would, but I'm not able to find the batch file in the source tree. It appears (to me) that the batch file is generated, and I don't know what to start looking for in order to fix this issue on my own.
> As such, I've created a test batch file (meant to be run on Windows) that I've attached to this Issue. When the issue is fixed, it should output something like this:
> {code}
> Calling "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT\bin\standalone.conf.bat"
> "JAVA_OPTS already set in environment; overriding default settings with values: "Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
> Setting JAVA property to "C:\bin\java\jdk8_u40_64\jre\bin\java"
> ===============================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT"
> JAVA: "C:\bin\java\jdk8_u40_64\jre\bin\java"
> JAVA_OPTS: "-Dprogram.name=standalone.bat "Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
> ===============================================================================
> Error: Could not find or load main class Look at me. LOOK AT ME. I am the JAVA_OPTS now.
> {code}
> The batch file can be acquired [here|https://cloud.githubusercontent.com/assets/2186874/7147925/844bc00c-...], just save the link as a batch file, or save it and change the extension (the same way that we get around email filters that don't let us send *.exe's). The way that I ran this was to put the batch file at the root of the Wildfly directory and then call it using window's CMD. The test case does several things:
> 1. Maven clean
> 2. Call build.bat
> 3. Set a JAVA_OPTS system variable
> 4. Call the standalone.bat in the new version of Wildfly that was created in step 2 (as long as the target dir is still wildfly-9.0.0.CR1-SNAPSHOT).
> I would love to take lead on fixing this, but I'm not sure where to start. If someone could give me a point in the right direction, that would be great. Thanks.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JBVFS-202) Invalid Local file header in ZIP file
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/JBVFS-202?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed JBVFS-202.
-----------------------------
Resolution: Cannot Reproduce Bug
I am closing this as I cannot reproduce the bug with information that was provided on this issue.
Reopen this only if you can provide more details on how to reproduce, preferably with attached deployment that causes the issue.
> Invalid Local file header in ZIP file
> -------------------------------------
>
> Key: JBVFS-202
> URL: https://issues.jboss.org/browse/JBVFS-202
> Project: JBoss VFS
> Issue Type: Bug
> Reporter: Martin Both
> Assignee: Tomaz Cerar
>
> I'm try to use the Embeddable EJBContainer of JBoss EAP 6.4.
> I get a ZipException: invalid CEN header (bad signature)
> JBoss writes an invalid Zip- file in
> JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6/content
> The reason is, that the zip file content contains a Local file header with no size for the file data. No Zip-Tool can unzip that and even JBoss cannot read that again.
> Compare the method bufferLocalFileHeader() with the method bufferNextCentralFileHeader() of class org.jboss.vfs,VirtualJarFileInputStream.
> The one wirtes file sizes the other one not. If you would read the file format specification of zip files than you would know that after the LocallFileHeader the file data is written. Without knowledge of the compressed size it is not possible to read that.
> Deployment with Embeddable EJBContainer does not work for me due to this bug.
> Trace:
> 2015-11-09 11:16:02,392 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.4.0.GA (AS 7.5.0.Final-redhat-21) wurde gestartet in 2502ms - 168 von 205 Diensten gestartet (61 Services sind "lazy", passiv oder werden bei Bedarf geladen)
> 2015-11-09 11:16:03,094 INFO [org.jboss.as.repository] (pool-4-thread-1) JBAS014900: Content an Speicherort C:\Users\A300859\workspaces\ProKom2.0_trunk\Servers\JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6\content hinzugefügt
> 2015-11-09 11:16:03,120 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starte Deployment von "classes" (runtime-name: "classes")
> 2015-11-09 11:16:03,159 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit.classes.STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment "classes" fehlgeschlagen
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:97) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 5 more
> Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)
> at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.8.0_60]
> at java.util.zip.ZipFile.<init>(ZipFile.java:219) [rt.jar:1.8.0_60]
> at java.util.zip.ZipFile.<init>(ZipFile.java:149) [rt.jar:1.8.0_60]
> at java.util.jar.JarFile.<init>(JarFile.java:166) [rt.jar:1.8.0_60]
> at java.util.jar.JarFile.<init>(JarFile.java:130) [rt.jar:1.8.0_60]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:90) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:77) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:386) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:410) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentMountProvider$Factory$ServerDeploymentRepositoryImpl.mountDeploymentContent(DeploymentMountProvider.java:105) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:93) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 6 more
> 2015-11-09 11:16:03,161 ERROR [org.jboss.as.controller.management-operation] (pool-4-thread-1) JBAS014612: Operation ("deploy") fehlgeschlagen - Adresse: ([("deployment" => "classes")]) - Fehlerbeschreibung: {"JBAS014671: Fehlgeschlagene Dienste" => {"jboss.deployment.unit.classes.STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment \"classes\" fehlgeschlagen
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
> Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)"}}
> 2015-11-09 11:16:03,163 ERROR [org.jboss.as.server] (pool-4-thread-1) JBAS015870: Deploy von Deployment "classes" wurde mit folgender Fehlermeldung zurückgesetzt:
> {"JBAS014671: Fehlgeschlagene Dienste" => {"jboss.deployment.unit.classes.STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment \"classes\" fehlgeschlagen
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
> Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)"}}
> 2015-11-09 11:16:03,165 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Deployment von classes in (runtime-name: "classes") 2ms gestoppt
> 2015-11-09 11:16:03,166 INFO [org.jboss.as.controller] (pool-4-thread-1) JBAS014774: Dienst-Statusbericht
> JBAS014777: Dienste, deren Start fehlgeschlagen ist: service jboss.deployment.unit.classes.STRUCTURE
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1065) Starting scripts not terminated on Solaris with LAUNCH_JBOSS_IN_BACKGROUND=true
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1065?page=com.atlassian.jira.plugi... ]
Tomaz Cerar closed WFCORE-1065.
-------------------------------
Resolution: Won't Fix
Behavior is the same on all *nix platforms. and such by intent.
> Starting scripts not terminated on Solaris with LAUNCH_JBOSS_IN_BACKGROUND=true
> -------------------------------------------------------------------------------
>
> Key: WFCORE-1065
> URL: https://issues.jboss.org/browse/WFCORE-1065
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Environment: Solaris 11 (x86, x86_64, sparc), Solaris 10 sparc
> Reporter: Tomáš Turek
> Assignee: Tomaz Cerar
>
> Standalone.sh script is not terminating when I run it with {{LAUNCH_JBOSS_IN_BACKGROUND=true}} on Solaris 11 OS. The problem is that after sending TERM signal to end standalone script. Then the jboss-module.jar is successfully terminated, but starting script gets into an infinite loop that constantly writes to log this:
> {code}
> + SIGNAL=15
> ++ kill -l 15
> + SIGNAL_NAME=TERM
> + echo '*** JBossAS process (12898) received TERM signal ***'
> *** JBossAS process (12898) received TERM signal ***
> + '[' 143 -ge 128 ']'
> + wait 12898
> + WAIT_STATUS=143
> + '[' 143 -gt 128 ']'
> ++ expr 143 - 128
> + SIGNAL=15
> ++ kill -l 15
> + SIGNAL_NAME=TERM
> + echo '*** JBossAS process (12898) received TERM signal ***'
> *** JBossAS process (12898) received TERM signal ***
> + '[' 143 -ge 128 ']'
> + wait 12898
> + WAIT_STATUS=143
> + '[' 143 -gt 128 ']'
> ++ expr 143 - 128
> + SIGNAL=15
> ++ kill -l 15
> + SIGNAL_NAME=TERM
> + echo '*** JBossAS process (12898) received TERM signal ***'
> *** JBossAS process (12898) received TERM signal ***
> + '[' 143 -ge 128 ']'
> + wait 12898
> + WAIT_STATUS=143
> + '[' 143 -gt 128 ']'
> ++ expr 143 - 128
> + SIGNAL=15
> ++ kill -l 15
> + SIGNAL_NAME=TERM
> + echo '*** JBossAS process (12898) received TERM signal ***'
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1147) Eliminate ProcessController
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1147?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1147:
-------------------------------------
Using a socket for input would mean that the server would also need an ack for its requests, in case the input socket dies. If we use stdin, then delivery is guaranteed: either the message gets to the client, or the client is killed.
> Eliminate ProcessController
> ---------------------------
>
> Key: WFCORE-1147
> URL: https://issues.jboss.org/browse/WFCORE-1147
> Project: WildFly Core
> Issue Type: Task
> Components: Server
> Reporter: David Lloyd
>
> We should eliminate ProcessController and directly have the HC control the servers. This should greatly simplify the code and add more power and flexibility to the management and lifecycle of server JVMs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1147) Eliminate ProcessController
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1147?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1147:
-------------------------------------
We would need an acknowledgement from the server of operation results regardless of whether stdin or socket were used for input channel, due to the buffering and unreliable nature of sockets. Once a result is acknowledged, we can discard it; otherwise hang on because we are either going to get an ack from the server or else the socket is going to time out/die, in which case, when we get a new socket to connect to, we must retransmit (in order) all our results.
> Eliminate ProcessController
> ---------------------------
>
> Key: WFCORE-1147
> URL: https://issues.jboss.org/browse/WFCORE-1147
> Project: WildFly Core
> Issue Type: Task
> Components: Server
> Reporter: David Lloyd
>
> We should eliminate ProcessController and directly have the HC control the servers. This should greatly simplify the code and add more power and flexibility to the management and lifecycle of server JVMs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1147) Eliminate ProcessController
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1147?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1147:
-------------------------------------
Because it's reliable i.e. there are fewer failure states. We don't have to worry about re-establishing if the child gets "lost". If the output-to-stdin stream hangs or dies, we can just immediately kill the child process because it's very, very likely to be a catastrophic error. If the return-to-server dies, we can continue passing orders to the client, including instructions for re-connecting the result stream.
>From the client perspective, if the stream-from-server ends, we exit immediately (with an exit code that communicates what happened to the server). If the stream-to-server dies, we just close it down and await new connect instructions, possibly buffering operation results in the meantime. This helps to ensure that no zombie servers will survive after the HC dies, which is AFAICT the most correct/reliable behavior.
> Eliminate ProcessController
> ---------------------------
>
> Key: WFCORE-1147
> URL: https://issues.jboss.org/browse/WFCORE-1147
> Project: WildFly Core
> Issue Type: Task
> Components: Server
> Reporter: David Lloyd
>
> We should eliminate ProcessController and directly have the HC control the servers. This should greatly simplify the code and add more power and flexibility to the management and lifecycle of server JVMs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1983) Discovery leaks responses
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1983?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1983:
--------------------------------
Oops, wrong! Discovery can also be triggered via the transport (TCP), so this *can* lead to leaks...
> Discovery leaks responses
> -------------------------
>
> Key: JGRP-1983
> URL: https://issues.jboss.org/browse/JGRP-1983
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> {{Discovery.ping_responses}} is never cleared, and leads to memory leaks if we have many discovery phases.
> Not really critical as discovery is usually done only once (at startup). However, {{MERGE2}} and {{MERGE}} still use it (they have been deprecated and will get removed in 4.0 though).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
