[JBoss JIRA] (DROOLS-5243) [DMN Designer] Boxed Expressions - Decision Table - Users cannot insert output columns by using the header
by Guilherme Gomes (Jira)
[ https://issues.redhat.com/browse/DROOLS-5243?page=com.atlassian.jira.plug... ]
Guilherme Gomes updated DROOLS-5243:
------------------------------------
Summary: [DMN Designer] Boxed Expressions - Decision Table - Users cannot insert output columns by using the header (was: [DMN Designer] Boxed Expressionss - Decision Table - Users cannot insert output columns by using the header)
> [DMN Designer] Boxed Expressions - Decision Table - Users cannot insert output columns by using the header
> ----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5243
> URL: https://issues.redhat.com/browse/DROOLS-5243
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Guilherme Gomes
> Priority: Critical
> Labels: drools-tools
> Attachments: bug.gif, workaround.gif
>
>
> Users cannot insert new output columns by using the Decision Table header. See how to *reproduce*:
> !bug.gif|width=600!
> However, users can insert new output columns by using regular table cells. See the *workaround*:
> !workaround.gif|width=600!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-815) Scatter/Gather to avoid copying
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-815?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-815.
---------------------------
Resolution: Duplicate Issue
> Scatter/Gather to avoid copying
> -------------------------------
>
> Key: JGRP-815
> URL: https://issues.redhat.com/browse/JGRP-815
> Project: JGroups
> Issue Type: Sub-task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Alpha5
>
> Attachments: bla10.java, bla9.java
>
>
> When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
> We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
> We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
> 1: Src and dest address plus flags, plus possibly size
> 2: The marshalled headers
> 3: The buffer passed to JGroups by the user
> We can obtain a gathering-write channel as follows:
> ByteBuffer[] buffers; // contains the 3 byte buffers above
> DatagramSocket sock;
> DatagramChannel ch=sock.getChannel();
> ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
> This is supported by a GatheringByteChannel.
> I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-815) Scatter/Gather to avoid copying
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-815?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-815 at 4/20/20 8:35 AM:
--------------------------------------------------------
This JIRA is moot, as we've already eliminated copying on the send path via JGRP-2218 and CompositeMessage \[1\].
When we decide to re-implement TCP_NIO2, we may still reconsider using gathering writes/scattering reads in the _transport_ itself. In other words, this is an implementation detail of the transport. See JGRP-2418 for details.
\[1\] http://www.jgroups.org/manual5/index.html#CompositeMessage
\[2\] https://issues.redhat.com/browse/JGRP-2418
was (Author: belaban):
This JIRA is moot, as we've already eliminated copying on the send path via JGRP-2218 and CompositeMessage \[1\].
When we decide to re-implement TCP_NIO2, we may still reconsider using gathering writes/scattering reads in the transport itself. See JGRP-2418 for details.
\[1\] http://www.jgroups.org/manual5/index.html#CompositeMessage
\[2\] https://issues.redhat.com/browse/JGRP-2418
> Scatter/Gather to avoid copying
> -------------------------------
>
> Key: JGRP-815
> URL: https://issues.redhat.com/browse/JGRP-815
> Project: JGroups
> Issue Type: Sub-task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Alpha5
>
> Attachments: bla10.java, bla9.java
>
>
> When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
> We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
> We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
> 1: Src and dest address plus flags, plus possibly size
> 2: The marshalled headers
> 3: The buffer passed to JGroups by the user
> We can obtain a gathering-write channel as follows:
> ByteBuffer[] buffers; // contains the 3 byte buffers above
> DatagramSocket sock;
> DatagramChannel ch=sock.getChannel();
> ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
> This is supported by a GatheringByteChannel.
> I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-815) Scatter/Gather to avoid copying
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-815?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-815:
-------------------------------
This JIRA is moot, as we've already eliminated copying on the send path via JGRP-2218 and CompositeMessage \[1\].
When we decide to re-implement TCP_NIO2, we may still reconsider using gathering writes/scattering reads in the transport itself. See JGRP-2418 for details.
\[1\] http://www.jgroups.org/manual5/index.html#CompositeMessage
\[2\] https://issues.redhat.com/browse/JGRP-2418
> Scatter/Gather to avoid copying
> -------------------------------
>
> Key: JGRP-815
> URL: https://issues.redhat.com/browse/JGRP-815
> Project: JGroups
> Issue Type: Sub-task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Alpha5
>
> Attachments: bla10.java, bla9.java
>
>
> When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
> We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
> We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
> 1: Src and dest address plus flags, plus possibly size
> 2: The marshalled headers
> 3: The buffer passed to JGroups by the user
> We can obtain a gathering-write channel as follows:
> ByteBuffer[] buffers; // contains the 3 byte buffers above
> DatagramSocket sock;
> DatagramChannel ch=sock.getChannel();
> ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
> This is supported by a GatheringByteChannel.
> I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months