[JBoss JIRA] (WFCORE-1861) Subsystem parsers should be created lazily when needed
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1861?page=com.atlassian.jira.plugi... ]
Tomaz Cerar moved STXM-16 to WFCORE-1861:
-----------------------------------------
Project: WildFly Core (was: StAXMapper)
Key: WFCORE-1861 (was: STXM-16)
Workflow: GIT Pull Request workflow (was: classic default workflow)
> Subsystem parsers should be created lazily when needed
> ------------------------------------------------------
>
> Key: WFCORE-1861
> URL: https://issues.jboss.org/browse/WFCORE-1861
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> Currently when we register parsers for different versions of subsystem schema we always pass over instance of whole parser which is usually statically initialized.
> In practice legacy (non current) parsers are only used rarely and there is no point in having them loaded in memory when not needed.
> Impl should be based on provider pattern and as such also allow us to on demand create new instance of parser when needed, as well as enable us for parsers to be GCed, when they are not in use.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1861) Subsystem parsers should be created lazily when needed
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1861?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1861:
--------------------------------
Component/s: Domain Management
> Subsystem parsers should be created lazily when needed
> ------------------------------------------------------
>
> Key: WFCORE-1861
> URL: https://issues.jboss.org/browse/WFCORE-1861
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> Currently when we register parsers for different versions of subsystem schema we always pass over instance of whole parser which is usually statically initialized.
> In practice legacy (non current) parsers are only used rarely and there is no point in having them loaded in memory when not needed.
> Impl should be based on provider pattern and as such also allow us to on demand create new instance of parser when needed, as well as enable us for parsers to be GCed, when they are not in use.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-848) "XNIO001001: No XNIO provider found" by some tests running with security manager
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-848?page=com.atlassian.jira.plugin... ]
Josef Cacek commented on WFCORE-848:
------------------------------------
[~pkremens] Thanks for the comment.
[~iweiss] Yes, as comments show in the JIRA Petr had mentioned, we are eager to consume Widfly Security Manager from the Core.
> "XNIO001001: No XNIO provider found" by some tests running with security manager
> --------------------------------------------------------------------------------
>
> Key: WFCORE-848
> URL: https://issues.jboss.org/browse/WFCORE-848
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.0.Alpha11
> Reporter: Petr Kremensky
> Assignee: Ingo Weiss
>
> Some tests in wildfly-core fails due to "XNIO001001: No XNIO provider found" while run with security manager enabled.
> {noformat}
> mvn test -Dtest=SuspendResumeTestCase -Dsecurity.manager -DtestLogToFile=false
> 10:27:16,814 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.test-undertow-server: org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> at org.xnio.Xnio.getInstance(Xnio.java:181)
> at io.undertow.Undertow.start(Undertow.java:97)
> at org.wildfly.test.suspendresumeendpoint.TestUndertowService.start(TestUndertowService.java:94)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 10:27:16,816 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "web-suspend.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
> Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> 10:27:16,817 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "web-suspend.jar" was rolled back with the following failure message:
> {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
> Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> {noformat}
> Affected tests found so far:
> * org.wildfly.core.test.standalone.suspend.web.SuspendResumeTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainGracefulShutdownTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainSuspendResumeTestCase
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-1925) Unclear error message about conflict
by Luca Bueti (JIRA)
[ https://issues.jboss.org/browse/WFLY-1925?page=com.atlassian.jira.plugin.... ]
Luca Bueti edited comment on WFLY-1925 at 10/10/16 9:11 AM:
------------------------------------------------------------
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on [JBoss EAP documentation|https://access.redhat.com/documentation/en-US/JBoss_Enterpr...] that explains that override and preserve commands work only for misc files. I verified that it's true by looking at wfly cli source code. In my humble opinion, the error message
_Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict._
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).
was (Author: luck17):
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on JBoss EAP documentation that explains that override and preserve commands work only for misc files. I verified that it's true by looking at wfly cli source code. In my humble opinion, the error message
_Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict._
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).
> Unclear error message about conflict
> ------------------------------------
>
> Key: WFLY-1925
> URL: https://issues.jboss.org/browse/WFLY-1925
> Project: WildFly
> Issue Type: Bug
> Components: Patching
> Reporter: Jan Martiska
> Assignee: Emanuel Muckenhuber
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> {noformat}
> [standalone@localhost:9990 /] patch apply /tmp/7e387d2d-a9de-4537-ad29-6f66ada17e53/77cc1914-21ea-4c9e-b023-d981b3cb80e0.zip
> Conflicts detected: jboss-modules.jar
> {noformat}
> That message doesn't say much. It should say something like 'the hash of xxx has changed, you have probably applied manual changes to xxx. Use --override or --preserve arguments to specify how the conflicts should be dealt with.'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-1925) Unclear error message about conflict
by Luca Bueti (JIRA)
[ https://issues.jboss.org/browse/WFLY-1925?page=com.atlassian.jira.plugin.... ]
Luca Bueti edited comment on WFLY-1925 at 10/10/16 9:11 AM:
------------------------------------------------------------
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on [JBoss EAP documentation|https://access.redhat.com/documentation/en-US/JBoss_Enterpr...] that explains that override and preserve commands work only for misc files. I verified this is true by looking at wfly cli source code. In my humble opinion, the error message
_Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict._
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).
was (Author: luck17):
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on [JBoss EAP documentation|https://access.redhat.com/documentation/en-US/JBoss_Enterpr...] that explains that override and preserve commands work only for misc files. I verified that it's true by looking at wfly cli source code. In my humble opinion, the error message
_Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict._
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).
> Unclear error message about conflict
> ------------------------------------
>
> Key: WFLY-1925
> URL: https://issues.jboss.org/browse/WFLY-1925
> Project: WildFly
> Issue Type: Bug
> Components: Patching
> Reporter: Jan Martiska
> Assignee: Emanuel Muckenhuber
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> {noformat}
> [standalone@localhost:9990 /] patch apply /tmp/7e387d2d-a9de-4537-ad29-6f66ada17e53/77cc1914-21ea-4c9e-b023-d981b3cb80e0.zip
> Conflicts detected: jboss-modules.jar
> {noformat}
> That message doesn't say much. It should say something like 'the hash of xxx has changed, you have probably applied manual changes to xxx. Use --override or --preserve arguments to specify how the conflicts should be dealt with.'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-1925) Unclear error message about conflict
by Luca Bueti (JIRA)
[ https://issues.jboss.org/browse/WFLY-1925?page=com.atlassian.jira.plugin.... ]
Luca Bueti edited comment on WFLY-1925 at 10/10/16 9:06 AM:
------------------------------------------------------------
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on JBoss EAP documentation that explains that override and preserve commands work only for misc files. I verified that it's true by looking at wfly cli source code. In my humble opinion, the error message
_Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict._
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).
was (Author: luck17):
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on JBoss EAP documentation that explains that override and preserve commands work only for misc files. In my humble opinion, the error message
Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict.
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).
> Unclear error message about conflict
> ------------------------------------
>
> Key: WFLY-1925
> URL: https://issues.jboss.org/browse/WFLY-1925
> Project: WildFly
> Issue Type: Bug
> Components: Patching
> Reporter: Jan Martiska
> Assignee: Emanuel Muckenhuber
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> {noformat}
> [standalone@localhost:9990 /] patch apply /tmp/7e387d2d-a9de-4537-ad29-6f66ada17e53/77cc1914-21ea-4c9e-b023-d981b3cb80e0.zip
> Conflicts detected: jboss-modules.jar
> {noformat}
> That message doesn't say much. It should say something like 'the hash of xxx has changed, you have probably applied manual changes to xxx. Use --override or --preserve arguments to specify how the conflicts should be dealt with.'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-1925) Unclear error message about conflict
by Luca Bueti (JIRA)
[ https://issues.jboss.org/browse/WFLY-1925?page=com.atlassian.jira.plugin.... ]
Luca Bueti commented on WFLY-1925:
----------------------------------
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on JBoss EAP documentation that explains that override and preserve commands work only for misc files. In my humble opinion, the error message
Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict.
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).
> Unclear error message about conflict
> ------------------------------------
>
> Key: WFLY-1925
> URL: https://issues.jboss.org/browse/WFLY-1925
> Project: WildFly
> Issue Type: Bug
> Components: Patching
> Reporter: Jan Martiska
> Assignee: Emanuel Muckenhuber
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> {noformat}
> [standalone@localhost:9990 /] patch apply /tmp/7e387d2d-a9de-4537-ad29-6f66ada17e53/77cc1914-21ea-4c9e-b023-d981b3cb80e0.zip
> Conflicts detected: jboss-modules.jar
> {noformat}
> That message doesn't say much. It should say something like 'the hash of xxx has changed, you have probably applied manual changes to xxx. Use --override or --preserve arguments to specify how the conflicts should be dealt with.'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2110) Transport: revisit buffers and threading
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2110:
---------------------------
Description:
(Concerns only the receiver side)
h4. Parsing
Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
h4. Buffers
* UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
* TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
* TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
h4. Approaches
# The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
# The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
# UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
# To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
h4. Goals
Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.
was:
(Concerns only the receiver side)
h4. Parsing
Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only receive fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
h4. Buffers
* UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
* TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
* TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
h4. Approaches
# The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
# The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
# UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
# To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
h4. Goals
Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.
> Transport: revisit buffers and threading
> ----------------------------------------
>
> Key: JGRP-2110
> URL: https://issues.jboss.org/browse/JGRP-2110
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> (Concerns only the receiver side)
> h4. Parsing
> Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
> This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
> h4. Buffers
> * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
> * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
> * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
> h4. Approaches
> # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
> # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
> # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
> # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
> h4. Goals
> Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months