[JBoss JIRA] (JGRP-2040) Seeing a OOM in JGroup 3.4
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2040?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2040:
--------------------------------
It might be that your clusters have overlapping port ranges; I suggest to pick ports that are spaced further apart, e.g. 35000, 36000 and 37000 with port_range of 0.
> Seeing a OOM in JGroup 3.4
> --------------------------
>
> Key: JGRP-2040
> URL: https://issues.jboss.org/browse/JGRP-2040
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Environment: Linux Operating System
> Reporter: Kshitiz Saxena
> Assignee: Bela Ban
>
> We are seeing an OOM in our application where thread dump points to JGroup.
> We see the below in thread dumps,
> 3XEHSTTYPE 07:33:24:346241000 GMT j9vm.294 - >setCurrentException index=11 constructorIndex=0 detailMessage=0000000000F61678
> 3XEHSTTYPE 07:33:24:346183000 GMT j9mm.126 - at 0000000050F8CD60 java/lang/Thread.run()V, jit 00007FCF323EA580, pc 00007FCF489E0A36
> 3XEHSTTYPE 07:33:24:346179000 GMT j9mm.126 - at 0000000053644748 *org/jgroups/blocks/TCPConnectionMap$TCPConnection$Receiver.run()*V, jit 0000000000000000, pc 00007FCF3354D334
> 3XEHSTTYPE 07:33:24:346175000 GMT j9mm.101 - J9AllocateIndexableObject() returning NULL! *1650814064 bytes* requested for object of class 0000000050F79700 from memory space 'Generational' id=00007FCF440427C0
> In the thread dump we also see
> WARNING : OutOfMemoryError possibly caused by 1650814064 bytes requested for object of class 0000000050F79700 from memory space 'Generational' id=00007FCF440427C0
> Java Heap Information
> -Xmx (Maximum Java heap size) : 1280m
> -Xms (Initial Java heap size) : 640m
> -Xss (Maximum stack size for Java threads) : 256k
> Total Java heap size: 1.25 GB
> Used Java heap size: 174.27 MB
> Free Java heap size: 1.08 GB
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6569) Vault.sh can create keystore when doesn't exist. But we can't define KEY_SIZE for it.
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6569?page=com.atlassian.jira.plugin.... ]
Lin Gao edited comment on WFLY-6569 at 5/16/16 9:56 PM:
--------------------------------------------------------
key-size is bound up with the algorithm.
Currently, {{vault.sh}} only allows algorithm: {{AES}}(no place to specify) to encrypt the sensitive data, for which the valid key sizes are: {{128}}, {{192}}, {{256}}. And for JDK like: Oracle JDKs, an additional installation of: {{Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files}} is needed to unlimit the strict of key size: {{192}} and {{256}}, otherwise only key-size: {{128}} is allowed to use.
It is not clear yet how to choose the algorithm, and which key size is valid for that algorithm when using the {{vault.sh}}, so I propose to reject this issue as won't fix, or change it into a REF?
was (Author: gaol):
key-size is bound up with the algorithm.
Currently, {{vault.sh}} only supports algorithm: {{AES}}(no place to specify) to encrypt the secret key, for which the valid key sizes are: {{128}}, {{192}}, {{256}}. And for JDK like: Oracle Java 8, an additional installation of: {{Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files}} is needed to unlimit the strict of key size: {{192}} and {{256}}, otherwise only key-size: {{128}} is allowed to use.
It is not clear yet how to choose the algorithm, and which key size is valid for that algorithm when using the {{vault.sh}}, so I propose to reject this issue as won't fix, or change it into a REF?
> Vault.sh can create keystore when doesn't exist. But we can't define KEY_SIZE for it.
> -------------------------------------------------------------------------------------
>
> Key: WFLY-6569
> URL: https://issues.jboss.org/browse/WFLY-6569
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Lin Gao
>
> Vault.sh can create keystore when doesn't exist. But we can't define KEY_SIZE for it.
> Vault.sh have -t, --create-keystore parameter for create new keystore when it doesn't exist.
> But we need define KEY_SIZE too in other case KEY_SIZE = 128 is used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6608) Not clear which input fields are required in resouce adapter add dialog
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6608?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-6608:
----------------------------------------
WFCORE-1556 is about some standard metadata changes that will make this kind of thing better described without relying on the text description.
> Not clear which input fields are required in resouce adapter add dialog
> -----------------------------------------------------------------------
>
> Key: WFLY-6608
> URL: https://issues.jboss.org/browse/WFLY-6608
> Project: WildFly
> Issue Type: Enhancement
> Affects Versions: 10.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 10.1.0.Final
>
>
> It is not clear which of inputs are required when I want to add new resource adapter. Only name is marked as required, but when I fill only name this error message appears:
> {code}
> Unexpected HTTP response: 500
> Request
> {
> "name" => "foobar",
> "archive" => undefined,
> "module" => undefined,
> "transaction-support" => undefined,
> "operation" => "add",
> "address" => [
> ("subsystem" => "resource-adapters"),
> ("resource-adapter" => "foobar")
> ]
> }
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "failure-description" => "WFLYJCA0077: At least one of ARCHIVE or MODULE is required",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-632) Subsystem deployment undeployed at startup
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-632?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-632:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1271673, https://bugzilla.redhat.com/show_bug.cgi?id=1336569 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1271673)
> Subsystem deployment undeployed at startup
> ------------------------------------------
>
> Key: WFCORE-632
> URL: https://issues.jboss.org/browse/WFCORE-632
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta3, 1.0.0.Beta4
> Reporter: Stan Silvert
> Assignee: Brian Stansberry
> Labels: affects_elytron
> Fix For: 1.0.0.Beta4
>
>
> {noformat}
> @BrianStansberry The "mixed approach" doesn't seem to work any more. https://developer.jboss.org/wiki/ExtendingAS7
> @BrianStansberry I'm using this to deploy keycloak WAR from the subsystem.
> @BrianStansberry As soon as the server is started, something is calling stopService() on the Keycloak WAR.
> Tomaz Cerar
> 1:15 PM
> @StanSilvert are you still working on AS7? https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8
> Stan Silvert
> 1:16 PM
> @ctomc No. this is WildFly 9. It still works on WildFly 8.
> Tomaz Cerar
> 1:16 PM
> ah the war deployment, that could be regression
> Brian Stansberry
> 1:17 PM
> @ctomc how so?
> Stan Silvert
> 1:17 PM
> FYI. I did a Thread.dumpStack() and got this:
> 13:11:35,173 ERROR [stderr] (MSC service thread 1-3) java.lang.Exception: Stack trace
> 13:11:35,173 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.dumpStack(Thread.java:1329)
> 13:11:35,174 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.Host.unregisterDeployment(Host.java:168)
> 13:11:35,176 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:
> 113)
> 13:11:35,179 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100)
> 13:11:35,181 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.Serv
> iceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> 13:11:35,184 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> 13:11:35,186 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 13:11:35,188 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 13:11:35,190 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.run(Thread.java:745)
> Hide full text
> Tomaz Cerar
> 1:18 PM
> @BrianStansberry just reffering that war deployment from subsystem should still work
> 1:19 PM
> Jason Greene joined the room.
> Tomaz Cerar
> 1:19 PM
> @StanSilvert what happens? as that thread dump makes no sense
> Stan Silvert
> 1:21 PM
> http://pastebin.com/xQ2DNzEe
> The WAR is simply undeployed as soon as WildFly finishes startup.
> Brian Stansberry
> 1:22 PM
> @StanSilvert can you give me a link to your code that's doing the deploy stuff?
> Stan Silvert
> 1:22 PM
> just a sec
> Stan Silvert
> 1:24 PM
> https://github.com/keycloak/keycloak/tree/master/integration
> The code that creates the operation is https://github.com/keycloak/keycloak/blob/master/integration
> AuthServerUtil ^^^
> click on the second link
> 1:27 PM
> Darran Lofthouse left the room.
> Brian Stansberry
> 1:27 PM
> @StanSilvert are you doing overlay stuff? I see some code there re: overlays
> Stan Silvert
> 1:28 PM
> Yes, but not in this instance.
> Brian Stansberry
> 1:28 PM
> ok. I'm asking just because that would add more complexity, better scope for some service dependency going missing, triggering stop
> Stan Silvert
> 1:29 PM
> For this simple case there are no overlays.
> Brian Stansberry
> 1:29 PM
> @StanSilvert interesting, your log looks like it's a true undeploy op, not just a service stop
> Tomaz Cerar
> 1:30 PM
> @BrianStansberry should we use 6.x.0 or 6.x.latest for tranformers testing?
> Tomaz Cerar goes get some diner
> Stan Silvert
> 1:30 PM
> @BrianStansberry If that's the case then maybe some condition is triggering my own undeploy operation.
> @BrianStansberry I'll look into that and see what I find.
> Brian Stansberry
> 1:31 PM
> @ctomc 6.x.0 is ok by me; chasing CPs is too much hassle
> @StanSilvert note this:
> 13:11:35,294 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0009: Undeployed "main-auth-server.war" (runtime-name: "main-auth-server.war")
> the thread -- DeploymentScanner-threads - 1
> looks like your deployment is exposed to the scanner?
> oh, here's a guess!
> the scanner sees "persistent" => false and treats it as under scanner control
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1555) Domain Setup docs doesn't explain domain.xml vs host.xml
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1555?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1555.
--------------------------------------
Resolution: Done
> Domain Setup docs doesn't explain domain.xml vs host.xml
> --------------------------------------------------------
>
> Key: WFCORE-1555
> URL: https://issues.jboss.org/browse/WFCORE-1555
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: John Mazzitelli
>
> There looks to be some information missing from:
> https://docs.jboss.org/author/display/WFLY10/Domain+Setup
> Or at least it is confusing. Notice that some of the instructions have this:
> "(See domain/configuration/host.xml)"
> and in other parts it has this:
> "(See domain/configuration/domain.xml)"
> Other than that, there is no mention of "host.xml" versus "domain.xml". This is confusing because the names of the files seem to infer that "domain.xml" is the configuration for the domain controller and "host.xml" is the configuration for the slave host controllers, but that clearly isn't the case (as the instructions both say to edit host.xml to configure both DC and HC). Both DC and HC's config files have:
> <host xmlns="urn:jboss:domain:3.0"> ...
> as the root node, whereas domain.xml has "<domain>".
> The docs should make it clear what and when domain.xml is used versus host.xml. It still isn't clear to me when domain.xml is used/when it is parsed. I assume it is read in by the DC during initialization.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1556:
----------------------------------------
Summary: Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
Key: WFCORE-1556
URL: https://issues.jboss.org/browse/WFCORE-1556
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
The handling of the notions of 'require'd and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general.
The read-resource-description output for an attribute doesn't show "required" at all.
After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place.
The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing.
And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically:
nillable = !required || alternatives != null
Right now, nillable is implemented as
nillable = !required
There are a number of problems I see with AttributeDefinition:
1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'.
2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change.
3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined.
4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived.
I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway.
Next would be to fix 3), by changing how AD validates.
Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly.
Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6616) Problems in DomainHostExcludes700TestCase
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6616?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-6616:
-----------------------------
Description:
The profile clone operation in the new DomainHostExcludes700TestCase.test003PostBootUpdates() in testsuite/mixed-domain fails with the following message:
{code}
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.messaging.activemq.server.default' is already registered in context 'profile=clone'."},
"rolled-back" => true
}
{code}
And we also see an error in
{code}
DomainHostExcludes700TestCase.test001SlaveBoot:45->DomainHostExcludesTest.test001SlaveBoot:217->DomainHostExcludesTest.checkSocketBindingGroups:300 ["full-ha-sockets"] expected:<2> but was:<1>
{code}
Some WIP to create this test is in my https://github.com/kabir/wildfly/tree/WFLY-6616 branch
was:
The profile clone operation in the new DomainHostExcludes700TestCase.test003PostBootUpdates() in testsuite/mixed-domain fails with the following message:
{code}
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.messaging.activemq.server.default' is already registered in context 'profile=clone'."},
"rolled-back" => true
}
And we also see an error in
{code}
DomainHostExcludes700TestCase.test001SlaveBoot:45->DomainHostExcludesTest.test001SlaveBoot:217->DomainHostExcludesTest.checkSocketBindingGroups:300 ["full-ha-sockets"] expected:<2> but was:<1>
{code}
> Problems in DomainHostExcludes700TestCase
> -----------------------------------------
>
> Key: WFLY-6616
> URL: https://issues.jboss.org/browse/WFLY-6616
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 11.0.0.Alpha1
>
>
> The profile clone operation in the new DomainHostExcludes700TestCase.test003PostBootUpdates() in testsuite/mixed-domain fails with the following message:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.messaging.activemq.server.default' is already registered in context 'profile=clone'."},
> "rolled-back" => true
> }
> {code}
> And we also see an error in
> {code}
> DomainHostExcludes700TestCase.test001SlaveBoot:45->DomainHostExcludesTest.test001SlaveBoot:217->DomainHostExcludesTest.checkSocketBindingGroups:300 ["full-ha-sockets"] expected:<2> but was:<1>
> {code}
> Some WIP to create this test is in my https://github.com/kabir/wildfly/tree/WFLY-6616 branch
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6616) Problems in DomainHostExcludes700TestCase
by Kabir Khan (JIRA)
Kabir Khan created WFLY-6616:
--------------------------------
Summary: Problems in DomainHostExcludes700TestCase
Key: WFLY-6616
URL: https://issues.jboss.org/browse/WFLY-6616
Project: WildFly
Issue Type: Feature Request
Components: Domain Management
Reporter: Kabir Khan
Assignee: Brian Stansberry
Fix For: 11.0.0.Alpha1
The profile clone operation in the new DomainHostExcludes700TestCase.test003PostBootUpdates() in testsuite/mixed-domain fails with the following message:
{code}
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.messaging.activemq.server.default' is already registered in context 'profile=clone'."},
"rolled-back" => true
}
And we also see an error in
{code}
DomainHostExcludes700TestCase.test001SlaveBoot:45->DomainHostExcludesTest.test001SlaveBoot:217->DomainHostExcludesTest.checkSocketBindingGroups:300 ["full-ha-sockets"] expected:<2> but was:<1>
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months