[JBoss JIRA] (JGRP-2154) FRAG3: create full message up front
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2154?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2154:
---------------------------
Description:
In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments: {{1:8000 2:8000 3:8000 4:6000}}.
When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
FRAG2's memory allocation is therefore:
* T1: 8000 // fragment 1 has been received
* T2: 16000 // fragment 2 has been received
* T3: 24000 // fragment 3 has been received
* T4: 30000 // fragment 4 has been received
* T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
Also, instead of allocating 60K of memory, only 30K are allocated.
The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
FRAG3's memory allocation looks as follows:
* T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
* T2: 30000 // fragment 2 has been received, copied into the full message and discarded
* T3: 30000 // fragment 3 has been received, copied into the full message and discarded
* T4: 30000 // fragment 4 has been received, copied into the full message and discarded
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
was:
In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments: {{1:8000 2:8000 3:8000 4:6000}}.
When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
FRAG2's memory allocation is therefore:
* T1: 8000 // fragment 1 has been received
* T2: 16000 // fragment 2 has been received
* T3: 24000 // fragment 3 has been received
* T4: 30000 // fragment 4 has been received
* T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
FRAG3's memory allocation looks as follows:
* T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
* T2: 30000 // fragment 2 has been received, copied into the full message and discarded
* T3: 30000 // fragment 3 has been received, copied into the full message and discarded
* T4: 30000 // fragment 4 has been received, copied into the full message and discarded
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
> FRAG3: create full message up front
> -----------------------------------
>
> Key: JGRP-2154
> URL: https://issues.jboss.org/browse/JGRP-2154
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments: {{1:8000 2:8000 3:8000 4:6000}}.
> When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
> FRAG2's memory allocation is therefore:
> * T1: 8000 // fragment 1 has been received
> * T2: 16000 // fragment 2 has been received
> * T3: 24000 // fragment 3 has been received
> * T4: 30000 // fragment 4 has been received
> * T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
> In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
> The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
> Also, instead of allocating 60K of memory, only 30K are allocated.
> The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
> FRAG3's memory allocation looks as follows:
> * T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
> * T2: 30000 // fragment 2 has been received, copied into the full message and discarded
> * T3: 30000 // fragment 3 has been received, copied into the full message and discarded
> * T4: 30000 // fragment 4 has been received, copied into the full message and discarded
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (WFCORE-1987) Create request/response reporting mechanism
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski updated WFCORE-1987:
---------------------------------------
Description:
In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284.
Scope of this enhancement are:
a) way to send back information
b) control level of "information" - just like in case of loggers
a) Information will be sent in response headers, under "warnings" key. Each entry, "warning" will contain operation, address, level/severity and i18n string with proper ID.
b) default level threshold would be "WARNING", if user requires more detailed information, he can request it via operation-headers->warninig-level
Example:
{noformat}
{
"outcome" => "success",
"response-headers" => {
"warnings" => [
{
"warning" => "WFLYCTL0436: Couldn't convert 'XXX' into proper warning level, threshold falling back to 'ALL'. Possible values: SEVERE,WARNING,INFO,CONFIG,FINE,FINER,FINEST",
"level" => "ALL",
"operation" => {
"address" => [
("subsystem" => "undertow"),
("server" => "default-server"),
("http-listener" => "default")
],
"operation" => "write-attribute"
}
},
{
"warning" => "WFLYUT0090: Worker used in http-listener: 'puppet-master', must be used in remoting subsystem.",
"level" => "WARNING",
"operation" => {
"address" => [
("subsystem" => "undertow"),
("server" => "default-server"),
("http-listener" => "default")
],
"operation" => "write-attribute"
}
}
],
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
{noformat}
was:
In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284.
Scope of this enhancment are:
a) way to send back information
b) control level of "information" - just like in case of loggers
a)
> Create request/response reporting mechanism
> -------------------------------------------
>
> Key: WFCORE-1987
> URL: https://issues.jboss.org/browse/WFCORE-1987
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Reporter: Radim Hatlapatka
> Assignee: Bartosz Baranowski
> Labels: downstream_dependency
>
> In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284.
> Scope of this enhancement are:
> a) way to send back information
> b) control level of "information" - just like in case of loggers
> a) Information will be sent in response headers, under "warnings" key. Each entry, "warning" will contain operation, address, level/severity and i18n string with proper ID.
> b) default level threshold would be "WARNING", if user requires more detailed information, he can request it via operation-headers->warninig-level
> Example:
> {noformat}
> {
> "outcome" => "success",
> "response-headers" => {
> "warnings" => [
> {
> "warning" => "WFLYCTL0436: Couldn't convert 'XXX' into proper warning level, threshold falling back to 'ALL'. Possible values: SEVERE,WARNING,INFO,CONFIG,FINE,FINER,FINEST",
> "level" => "ALL",
> "operation" => {
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("http-listener" => "default")
> ],
> "operation" => "write-attribute"
> }
> },
> {
> "warning" => "WFLYUT0090: Worker used in http-listener: 'puppet-master', must be used in remoting subsystem.",
> "level" => "WARNING",
> "operation" => {
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("http-listener" => "default")
> ],
> "operation" => "write-attribute"
> }
> }
> ],
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (JGRP-2154) FRAG3: create full message up front
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2154?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2154:
---------------------------
Description:
In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments: {{1:8000 2:8000 3:8000 4:6000}}.
When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
FRAG2's memory allocation is therefore:
* T1: 8000 // fragment 1 has been received
* T2: 16000 // fragment 2 has been received
* T3: 24000 // fragment 3 has been received
* T4: 30000 // fragment 4 has been received
* T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
FRAG3's memory allocation looks as follows:
* T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
* T2: 30000 // fragment 2 has been received, copied into the full message and discarded
* T3: 30000 // fragment 3 has been received, copied into the full message and discarded
* T4: 30000 // fragment 4 has been received, copied into the full message and discarded
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
was:
In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments: {{1: 8000 2:8000 3:8000 4:6000}}.
When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
FRAG2's memory allocation is therefore:
* T1: 8000 // fragment 1 has been received
* T2: 16000 // fragment 2 has been received
* T3: 24000 // fragment 3 has been received
* T4: 30000 // fragment 4 has been received
* T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
FRAG3's memory allocation looks as follows:
* T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
* T2: 30000 // fragment 2 has been received, copied into the full message and discarded
* T3: 30000 // fragment 3 has been received, copied into the full message and discarded
* T4: 30000 // fragment 4 has been received, copied into the full message and discarded
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
> FRAG3: create full message up front
> -----------------------------------
>
> Key: JGRP-2154
> URL: https://issues.jboss.org/browse/JGRP-2154
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments: {{1:8000 2:8000 3:8000 4:6000}}.
> When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
> FRAG2's memory allocation is therefore:
> * T1: 8000 // fragment 1 has been received
> * T2: 16000 // fragment 2 has been received
> * T3: 24000 // fragment 3 has been received
> * T4: 30000 // fragment 4 has been received
> * T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
> In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
> The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
> The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
> FRAG3's memory allocation looks as follows:
> * T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
> * T2: 30000 // fragment 2 has been received, copied into the full message and discarded
> * T3: 30000 // fragment 3 has been received, copied into the full message and discarded
> * T4: 30000 // fragment 4 has been received, copied into the full message and discarded
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (JGRP-2154) FRAG3: create full message up front
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2154?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2154:
---------------------------
Description:
In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments: {{1: 8000 2:8000 3:8000 4:6000}}.
When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
FRAG2's memory allocation is therefore:
* T1: 8000 // fragment 1 has been received
* T2: 16000 // fragment 2 has been received
* T3: 24000 // fragment 3 has been received
* T4: 30000 // fragment 4 has been received
* T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
FRAG3's memory allocation looks as follows:
* T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
* T2: 30000 // fragment 2 has been received, copied into the full message and discarded
* T3: 30000 // fragment 3 has been received, copied into the full message and discarded
* T4: 30000 // fragment 4 has been received, copied into the full message and discarded
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
was:
In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments:
`1: 8000 2:8000 3:8000 4:6000`.
When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
FRAG2's memory allocation is therefore:
* T1: 8000 // fragment 1 has been received
* T2: 16000 // fragment 2 has been received
* T3: 24000 // fragment 3 has been received
* T4: 30000 // fragment 4 has been received
* T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
FRAG3's memory allocation looks as follows:
* T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
* T2: 30000 // fragment 2 has been received, copied into the full message and discarded
* T3: 30000 // fragment 3 has been received, copied into the full message and discarded
* T4: 30000 // fragment 4 has been received, copied into the full message and discarded
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
> FRAG3: create full message up front
> -----------------------------------
>
> Key: JGRP-2154
> URL: https://issues.jboss.org/browse/JGRP-2154
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments: {{1: 8000 2:8000 3:8000 4:6000}}.
> When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
> FRAG2's memory allocation is therefore:
> * T1: 8000 // fragment 1 has been received
> * T2: 16000 // fragment 2 has been received
> * T3: 24000 // fragment 3 has been received
> * T4: 30000 // fragment 4 has been received
> * T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
> In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
> The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
> The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
> FRAG3's memory allocation looks as follows:
> * T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
> * T2: 30000 // fragment 2 has been received, copied into the full message and discarded
> * T3: 30000 // fragment 3 has been received, copied into the full message and discarded
> * T4: 30000 // fragment 4 has been received, copied into the full message and discarded
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (JGRP-2154) FRAG3: create full message up front
by Bela Ban (JIRA)
Bela Ban created JGRP-2154:
------------------------------
Summary: FRAG3: create full message up front
Key: JGRP-2154
URL: https://issues.jboss.org/browse/JGRP-2154
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0
In FRAG2, a full message to be passed up the stackj is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments:
`1: 8000 2:8000 3:8000 4:6000`.
When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
FRAG2's memory allocation is therefore:
* T1: 8000 // fragment 1 has been received
* T2: 16000 // fragment 2 has been received
* T3: 24000 // fragment 3 has been received
* T4: 30000 // fragment 4 has been received
* T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
FRAG3's memory allocation looks as follows:
* T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
* T2: 30000 // fragment 2 has been received, copied into the full message and discarded
* T3: 30000 // fragment 3 has been received, copied into the full message and discarded
* T4: 30000 // fragment 4 has been received, copied into the full message and discarded
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (JGRP-2154) FRAG3: create full message up front
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2154?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2154:
---------------------------
Description:
In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments:
`1: 8000 2:8000 3:8000 4:6000`.
When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
FRAG2's memory allocation is therefore:
* T1: 8000 // fragment 1 has been received
* T2: 16000 // fragment 2 has been received
* T3: 24000 // fragment 3 has been received
* T4: 30000 // fragment 4 has been received
* T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
FRAG3's memory allocation looks as follows:
* T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
* T2: 30000 // fragment 2 has been received, copied into the full message and discarded
* T3: 30000 // fragment 3 has been received, copied into the full message and discarded
* T4: 30000 // fragment 4 has been received, copied into the full message and discarded
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
was:
In FRAG2, a full message to be passed up the stackj is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments:
`1: 8000 2:8000 3:8000 4:6000`.
When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
FRAG2's memory allocation is therefore:
* T1: 8000 // fragment 1 has been received
* T2: 16000 // fragment 2 has been received
* T3: 24000 // fragment 3 has been received
* T4: 30000 // fragment 4 has been received
* T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
FRAG3's memory allocation looks as follows:
* T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
* T2: 30000 // fragment 2 has been received, copied into the full message and discarded
* T3: 30000 // fragment 3 has been received, copied into the full message and discarded
* T4: 30000 // fragment 4 has been received, copied into the full message and discarded
* T4: 30000 // full message is being delivered up the stack, and fragments have been removed
* T5: 0 // full message has been delivered and can be garbage collected
> FRAG3: create full message up front
> -----------------------------------
>
> Key: JGRP-2154
> URL: https://issues.jboss.org/browse/JGRP-2154
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments:
> `1: 8000 2:8000 3:8000 4:6000`.
> When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
> FRAG2's memory allocation is therefore:
> * T1: 8000 // fragment 1 has been received
> * T2: 16000 // fragment 2 has been received
> * T3: 24000 // fragment 3 has been received
> * T4: 30000 // fragment 4 has been received
> * T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
> In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
> The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
> The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
> FRAG3's memory allocation looks as follows:
> * T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
> * T2: 30000 // fragment 2 has been received, copied into the full message and discarded
> * T3: 30000 // fragment 3 has been received, copied into the full message and discarded
> * T4: 30000 // fragment 4 has been received, copied into the full message and discarded
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (WFCORE-1987) Create request/response reporting mechanism
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski updated WFCORE-1987:
---------------------------------------
Description:
In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284.
Scope of this enhancment are:
a) way to send back information
b) control level of "information" - just like in case of loggers
a)
was:In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284.
> Create request/response reporting mechanism
> -------------------------------------------
>
> Key: WFCORE-1987
> URL: https://issues.jboss.org/browse/WFCORE-1987
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Reporter: Radim Hatlapatka
> Assignee: Bartosz Baranowski
> Labels: downstream_dependency
>
> In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284.
> Scope of this enhancment are:
> a) way to send back information
> b) control level of "information" - just like in case of loggers
> a)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (WFCORE-1987) Create request/response reporting mechanism
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski updated WFCORE-1987:
---------------------------------------
Description: In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284. (was: In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance )
> Create request/response reporting mechanism
> -------------------------------------------
>
> Key: WFCORE-1987
> URL: https://issues.jboss.org/browse/WFCORE-1987
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Reporter: Radim Hatlapatka
> Assignee: Bartosz Baranowski
> Labels: downstream_dependency
>
> In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (WFCORE-1987) Create request/response reporting mechanism
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski updated WFCORE-1987:
---------------------------------------
Description: In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance (was: In EAP 7.0.0, there was possible to define different worker for Undertow listener and Remoting.
Now it is not possible and results in \[1\].
The need for having the same XNIO worker used for both Remoting endpoint and Undertow listener used for the http-upgrade should be exposed when doing the configuration changes, either it should be allowed or proper warning shown (at least having it documented in both descriptions and in documentation, including the migration guide), for user to know that such configuration can result in not working remoting calls.
Note, this change in behaviour was introduced when upgrading to XNIO 3.4.0.Final. This might seem as backward compatibility issue from customer as his original configuration working with EAP 7.0.0 will stop working.
\[1\]
{noformat}
08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at Automaticio.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkC08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelAutomaticAutomaticListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)Automatic
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
at io.undertow.server.protocol.http.HttpReadListener.excAutomatichangeComplete(HttpReadListener.java:372)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListeAutomaticner(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
hannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
{noformat})
> Create request/response reporting mechanism
> -------------------------------------------
>
> Key: WFCORE-1987
> URL: https://issues.jboss.org/browse/WFCORE-1987
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Reporter: Radim Hatlapatka
> Assignee: Bartosz Baranowski
> Labels: downstream_dependency
>
> In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (WFCORE-1987) Create request/response reporting mechanism
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski updated WFCORE-1987:
---------------------------------------
Summary: Create request/response reporting mechanism (was: Unable to define specific worker when using http-upgrade)
> Create request/response reporting mechanism
> -------------------------------------------
>
> Key: WFCORE-1987
> URL: https://issues.jboss.org/browse/WFCORE-1987
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Reporter: Radim Hatlapatka
> Assignee: Bartosz Baranowski
> Labels: downstream_dependency
>
> In EAP 7.0.0, there was possible to define different worker for Undertow listener and Remoting.
> Now it is not possible and results in \[1\].
> The need for having the same XNIO worker used for both Remoting endpoint and Undertow listener used for the http-upgrade should be exposed when doing the configuration changes, either it should be allowed or proper warning shown (at least having it documented in both descriptions and in documentation, including the migration guide), for user to know that such configuration can result in not working remoting calls.
> Note, this change in behaviour was introduced when upgrading to XNIO 3.4.0.Final. This might seem as backward compatibility issue from customer as his original configuration working with EAP 7.0.0 will stop working.
> \[1\]
> {noformat}
> 08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at Automaticio.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> 08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkC08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> 08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelAutomaticAutomaticListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> 08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)Automatic
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
> at io.undertow.server.protocol.http.HttpReadListener.excAutomatichangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListeAutomaticner(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> hannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
- 1
- 0