[JBoss JIRA] (WFLY-5803) The org.jboss.metadata module isn't marked 'private'
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-5803:
--------------------------------------
Summary: The org.jboss.metadata module isn't marked 'private'
Key: WFLY-5803
URL: https://issues.jboss.org/browse/WFLY-5803
Project: WildFly
Issue Type: Bug
Components: EE
Affects Versions: 10.0.0.CR4
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 10.0.0.CR5
The fix for WFLY-3806 restored the org.jboss.metadata module but did not restore its previous jboss.api=private setting.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1123) Recreate HttpPostMgmtOpsTestCase.testAddRemove
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1123?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-1123:
-----------------------------------------
Assignee: ehsavoie Hugonnet
> Recreate HttpPostMgmtOpsTestCase.testAddRemove
> ----------------------------------------------
>
> Key: WFCORE-1123
> URL: https://issues.jboss.org/browse/WFCORE-1123
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> HttpPostMgmtOpsTestCase.testAddRemove was ignored when the test was moved from full to core because the test impl used undertow subsystem resources.
> We should resurrect this test, using resources in core.
> The goal of the test is to execute add and remove ops via POST, not to test add/remove of a particular resource. So the task is not to move the test to full and test undertow subsystem, it's to make POST calls against core that add/remove.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1991) TCP_NIO2: copy on demand
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1991?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1991:
--------------------------------
UnitTest: {{BuffersTest.testPartialWriteWithCopy()}}
> TCP_NIO2: copy on demand
> ------------------------
>
> Key: JGRP-1991
> URL: https://issues.jboss.org/browse/JGRP-1991
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> When TCP_NIO2 writes data, we always pass a copy of data of it, because of JGRP-1961 [1].
> However, if we copied the data only on a *partial write* (full writes don't need a copy), then we could always pass data from reused buffers down to the transport.
> Example: we want to write 3 buffers of 100, 200 and 700 bytes in a gathering write (the buffers are allocated from reusable byte[] arrays).
> If the write returns 1000, we know that all 3 buffers have been written and there is no need to copy any of the buffers. However, if only 500 bytes were written, then we can trash the first 2 buffers, but need to make a copy of the 3rd buffer in range [201 .. 700].
> This allows the sender to reuse previously allocated buffers, as all transports (UDP, TCP, TCP_NIO2) now guarantee that, on return of the send(), either the data was written completely, or a copy was made.
> [1] https://issues.jboss.org/browse/JGRP-1961
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1991) TCP_NIO2: copy on demand
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1991?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1991:
--------------------------------
There will be a additional method {{Buffers.copy()}} which copies the data in range {{last_copied .. limit}} and moves {{last_copied}} to {{limit}}. Next time {{copy()}} is invoked, unless {{limit}} has moved, there won't be any copy.
{{Buffers.copy()}} would typically be called after a {{Buffers.write()}} returned false (partial write). It would be called by the user, which knows whether data needs to be copied in the first place. For example, if the user already passes copies into the {{write()}} call, then {{Buffers.copy()}} would not have to be called.
> TCP_NIO2: copy on demand
> ------------------------
>
> Key: JGRP-1991
> URL: https://issues.jboss.org/browse/JGRP-1991
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> When TCP_NIO2 writes data, we always pass a copy of data of it, because of JGRP-1961 [1].
> However, if we copied the data only on a *partial write* (full writes don't need a copy), then we could always pass data from reused buffers down to the transport.
> Example: we want to write 3 buffers of 100, 200 and 700 bytes in a gathering write (the buffers are allocated from reusable byte[] arrays).
> If the write returns 1000, we know that all 3 buffers have been written and there is no need to copy any of the buffers. However, if only 500 bytes were written, then we can trash the first 2 buffers, but need to make a copy of the 3rd buffer in range [201 .. 700].
> This allows the sender to reuse previously allocated buffers, as all transports (UDP, TCP, TCP_NIO2) now guarantee that, on return of the send(), either the data was written completely, or a copy was made.
> [1] https://issues.jboss.org/browse/JGRP-1961
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1961?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1961 at 12/7/15 10:35 AM:
----------------------------------------------------------
Hmm, how about we push the copy logic into {{WriteBuffers}} which could be configured to enable/disable copying on an unsuccessful write: if a {{write(b1,b2,b3,b4)}} was unsuccessful and only wrote {{b1}}, {{b2}} and *parts of* {{b3}}, but not {{b4}}, then null {{b1}} and {{b2}} and *copy* {{b3}} and {{b4}}, leaving {{position}} and {{limit}} of {{b3}} and {{b4}} intact.
Hmm, what happens if the next write also fails ? How do we prevent an additional copy ? Perhaps we need to introduce a {{last_copied}} field which keeps track of which buffers have already been copied...
was (Author: belaban):
Hmm, how about we push the copy logic into {{WriteBuffers}} which could be configured to enable/disable copying on an unsuccessful write: if a {{write(b1,b2,b3,b4)}} was unsuccessful and only wrote {{b1}}, {{b2}} and *parts of* {{b3}}, but not {{b4}}, then null {{b1}} and {{b2}} and *copy* {{b3}} and {{b4}}, leaving {{position}} and {{limit}} of {{b3}} and {{b4}} intact.
Hmm, what happens if the next write also fails ? How do we prevent an additional copy ?
> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
> Key: JGRP-1961
> URL: https://issues.jboss.org/browse/JGRP-1961
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} and {{UDP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1961?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1961 at 12/7/15 10:34 AM:
----------------------------------------------------------
For non-bundled messages, we create a new buffer for every message: those buffers are not reused. In contrast, message bundlers create a buffer (initial size: 1024 bytes) which is always reused and thus potentially increases.
Perhaps we need to abandon this and create a new buffer in bundlers for every message, too, like for non bundled messages...
Downside: this affects {{TCP}} and {{UDP}} which don't need to copy.
Is blindly copying in {{TCP_NIO2}} an option ? The copies would be unneeded for non-bundled messages, but I guess most messages are bundled, so this should be ok...
Copying in {{TCP_NIO2}} is similar to copying in {{TCP}}, with send-queues being enabled...
was (Author: belaban):
For non-bundled messages, we create a new buffer for every message: those buffers are not reused. In contrast, message bundlers create a buffer (initial size: 1024 bytes) which is always reused and thus potentially increases.
Perhaps we need to abandon this and create a new buffer in bundlers for every message, too, like for non bundled messages...
Downside: this affects {{TCP}} and {{UDP}} which don't need to copy.
Is blindly copying in {{TCP_PING}} an option ? The copies would be unneeded for non-bundled messages, but I guess most messages are bundled, so this should be ok...
Copying in {{TCP_NIO2}} is similar to copying in {{TCP}}, with send-queues being enabled...
> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
> Key: JGRP-1961
> URL: https://issues.jboss.org/browse/JGRP-1961
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} and {{UDP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1961) TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1961?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1961:
---------------------------
Description:
When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
This works for {{TCP}} and {{UDP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
A quick check where buffers were copied fixed the problem.
TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.
was:
When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
This works for {{TCP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
A quick check where buffers were copied fixed the problem.
TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.
> TCP_NIO2: message bundling can lead to corruption of msgs sent asynchronously
> -----------------------------------------------------------------------------
>
> Key: JGRP-1961
> URL: https://issues.jboss.org/browse/JGRP-1961
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.6
>
>
> When a message is sent with a message bundler (in {{TP}}), the output buffer in {{TP.BaseBundler}} is reused for all messages of a given bundle (say {{m1}} and {{m2}}).
> This works for {{TCP}} and {{UDP}} because a write _blocks_ and - when it returns - we're guaranteed that the buffer has been copied into an OS buffer (TCP's send window).
> However, this is different with {{TCP_NIO2}}: *an async write always returns immediately, irrespective of whether the data was written completely, partially, or not at all !*
> If a write only writes a part of its data, on returning from the write, the message bundler reuses the output buffer and can thus overwrite and corrupt buffers that are in transit, waiting to be written.
> A quick check where buffers were copied fixed the problem.
> TODO: see where we need to copy data when using a bundler. Possibly only copy if a write didn't write all of the data.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1951) Flexible buffers for scatter/gather
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1951?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1951.
----------------------------
Resolution: Done
Individual buffers can now be added, removed, and accessed
> Flexible buffers for scatter/gather
> -----------------------------------
>
> Key: JGRP-1951
> URL: https://issues.jboss.org/browse/JGRP-1951
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> Currently, {{Buffers}} and {{WriteBuffers}} are inflexible in that they always expect a length buffer followed by data ({{Buffers}}), or a sequence of len/data pairs ({{WriteBuffers}}).
> This is bad if we for example want to read a sequence like the one below (for connection establishment in TCP):
> {noformat}
> | cookie | version | len | peer-address |
> (4) (2) (2) (variable)
> {noformat}
> Goals:
> * Have only 1 buffer, for reading *and* writing
> * Allow to define the sequence by adding buffers dynamically, e.g. in the above case, we'd add a 4 and a 2-length buffer and read data into them. If the cookie and version don't match, throw an exception, else *dynamically* add a length buffer (possibly doing a clear() which removes the first 2 buffers), read data into it, then add a new buffer sized to the read length and finally read data into it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months