[JBoss JIRA] (DROOLS-3447) Remove "DMN Asset" dependency from TitledAttachmentFileWidget
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-3447?page=com.atlassian.jira.plug... ]
Gabriele Cardosi reassigned DROOLS-3447:
----------------------------------------
Assignee: Yeser Amer (was: Gabriele Cardosi)
> Remove "DMN Asset" dependency from TitledAttachmentFileWidget
> -------------------------------------------------------------
>
> Key: DROOLS-3447
> URL: https://issues.redhat.com/browse/DROOLS-3447
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools
>
> Currently, TitledAttachmentFileWidget use ProjectAssetsQuery to retrieve the "dmn" files.
> Implicitly, this means that *if* (for whatever reason) dmn editor is disabled, the dmn file are not retrieved. Wording differently, this creates an implicit dependency between scenariosimulation and dmn editor.
> Fix it so that TitledAttachmentFileWidget could find dmn files regardless of dmn editor.
> Look at left dock that shows all the files of the project.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2417) Ref-counting for messages
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2417?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2417:
---------------------------
Description:
When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done.
However, the return of a {{Channel.send()}} call does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table.
Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool.
This could possibly be a trait, with a no-op implementation as default. This could be overwritten, ie.
{code:java}
Message release() {
if(refcount <= 0)
// give associated memory area back to pool
}
{code}
See if this needs to be integrated with {{MessageFactory}} as well.
was:
When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done.
However, {{Channel.send()}} does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table.
Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool.
This could possibly be a trait, with a no-op implementation as default. This could be overwritten, ie.
{code:java}
Message release() {
if(refcount <= 0)
// give associated memory area back to pool
}
{code}
See if this needs to be integrated with {{MessageFactory}} as well.
> Ref-counting for messages
> -------------------------
>
> Key: JGRP-2417
> URL: https://issues.redhat.com/browse/JGRP-2417
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0
>
>
> When users do their own memory management, the message passed to {{Channel.send()}} might have a reference to a memory area that's allocated from a pool, and that needs to be returned when done.
> However, the return of a {{Channel.send()}} call does not necessarily mean that the memory area can be reused. If, for example, NAKACK2 or UNICAST3 have the message in their retransmission tables (to potentially retransmit it), then the memory cannot be reused until that message has been purged from the retransmission table.
> Add a reference-counting mechanism to {{Message}} (implemented in {{BaseMessage}}) that allows NAKACK2 or UNICAST3 to increment a ref-count. When a message is purged from the retransmission table, decrement its ref-count. When the ref-count is 0, a callback could be called. The callback could for example return the associated memory chunk back to the memory pool.
> This could possibly be a trait, with a no-op implementation as default. This could be overwritten, ie.
> {code:java}
> Message release() {
> if(refcount <= 0)
> // give associated memory area back to pool
> }
> {code}
> See if this needs to be integrated with {{MessageFactory}} as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4838) Create common producer for tests
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4838?page=com.atlassian.jira.plug... ]
Gabriele Cardosi reassigned DROOLS-4838:
----------------------------------------
Assignee: Yeser Amer (was: Gabriele Cardosi)
> Create common producer for tests
> --------------------------------
>
> Key: DROOLS-4838
> URL: https://issues.redhat.com/browse/DROOLS-4838
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools
>
> Inside the tests there is a whole bunch of mocked objects that are used in multiple places (especially the ones related to grid/cell/rendering stuff).
> Scope of this ticket shuold be to put all of them inside a static producer; this would also reduce the needs for abstract/inheritance chains, simplifying the test environment
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4769) Add an empty row on grid when importing "empty" csv
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4769?page=com.atlassian.jira.plug... ]
Gabriele Cardosi reassigned DROOLS-4769:
----------------------------------------
Assignee: Yeser Amer (was: Gabriele Cardosi)
> Add an empty row on grid when importing "empty" csv
> ---------------------------------------------------
>
> Key: DROOLS-4769
> URL: https://issues.redhat.com/browse/DROOLS-4769
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Affects Versions: 7.30.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools
> Attachments: DmnAssert.scesim, DmnAssert.scesim.csv, Driver Suspension Rules.dmn, image.png
>
>
> If user import csv file in DMN scenario, which contains only header, then the Background contains no rows see [^image.png]
> Steps to reproduce :
> # Import [^Driver Suspension Rules.dmn]
> # Import [^DmnAssert.scesim]
> # In scesim file import [^DmnAssert.scesim.csv]
> Expected: Grid with the cells state the same as after initialization
> Actual: user has no rows to add a value
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months