November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3054) (7.1.0) Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop.

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3054?page=com.atlassian.jira.plugi... ] Jean-Francois Denise resolved WFCORE-3054. ------------------------------------------ Fix Version/s: 3.0.6.Final Resolution: Done > (7.1.0) Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop. > -------------------------------------------------------------------------------------- > > Key: WFCORE-3054 > URL: https://issues.jboss.org/browse/WFCORE-3054 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Critical > Fix For: 3.0.6.Final > > > *Description of problem:* > Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop. > *Steps to Reproduce:* > # configure https > # loop, more clients in parralel: > #* ./jboss-cli.sh -c ":read-attribute(name=server-state)" -Djavax.net.ssl.trustStore=... -Djavax.net.ssl.trustStorePassword=... > *How reproducible:* > Intermittently > *Actual results:* > Thread dump is attached -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime

by Matthew Stevens (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ] Matthew Stevens commented on DROOLS-1825: ----------------------------------------- It looks like the first part of this (the ability to set Hit Policy to None) is already done. As for changing the policy later, I would recommend that the Hit Policy dropdown appear on the Overview tab. I do not see a property panel for GDT so the Overview tab seems like the best option. Do you agree [~ibek] [~manstis] [~Rikkola]? > [Guided Decision Table] Ability to change HIT policy in a decision table anytime > -------------------------------------------------------------------------------- > > Key: DROOLS-1825 > URL: https://issues.jboss.org/browse/DROOLS-1825 > Project: Drools > Issue Type: Enhancement > Components: Guided Decision Table Editor > Affects Versions: 7.1.0.Beta2 > Reporter: Ivo Bek > Assignee: Toni Rikkola > Priority: Critical > Original Estimate: 1 week > Remaining Estimate: 1 week > > Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy. > Thus, it should be possible to change HIT policy in a decision table anytime. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3409) embed-server doesn't honor "module.path" system property

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3409?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3409: ------------------------------------------ This needs to go to [~luck3y]. He's doing a lot of stuff in this area. > embed-server doesn't honor "module.path" system property > -------------------------------------------------------- > > Key: WFCORE-3409 > URL: https://issues.jboss.org/browse/WFCORE-3409 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 4.0.0.Alpha2 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Every other parts of server and launchers (including embed-host-controller) honor the "module.path" system property for setting modules path. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1811) [Guided Decision Table] Column Wizard usability improvements

by Matthew Stevens (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1811?page=com.atlassian.jira.plugi... ] Matthew Stevens commented on DROOLS-1811: ----------------------------------------- These proposals are fine with me. Adding [~stetson.robinson] and [~cwatkins] for blue "info" text for Calculation Type and Value List. > [Guided Decision Table] Column Wizard usability improvements > ------------------------------------------------------------ > > Key: DROOLS-1811 > URL: https://issues.jboss.org/browse/DROOLS-1811 > Project: Drools > Issue Type: Enhancement > Components: Guided Decision Table Editor > Affects Versions: 7.2.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Carreiro > Fix For: 7.5.0.Final > > Original Estimate: 3 days > Remaining Estimate: 3 days > > On the _BRMS 7.0 - Getting Started Experience_ meeting, there were mentioned these points that could improve the column wizard: > - Placement of input fields > -- *Field binding* should be on the same page as *Field* > -- Pages like *Operator* and *Field* could be merged or at least recapitulate what was selected on previous pages of the wizard > - Input fields should be explained somehow. For newbies it is really hard to understand what is the *Calculation Type* or *Value List*. I liked concept of small _i_ in blue circle that shows hint after mouse is over this info sign. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3409) embed-server doesn't honor "module.path" system property

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-3409: ----------------------------------- Summary: embed-server doesn't honor "module.path" system property Key: WFCORE-3409 URL: https://issues.jboss.org/browse/WFCORE-3409 Project: WildFly Core Issue Type: Bug Components: Server Affects Versions: 4.0.0.Alpha2 Reporter: Tomaz Cerar Assignee: Tomaz Cerar Every other parts of server and launchers (including embed-host-controller) honor the "module.path" system property for setting modules path. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3120) Tests broken as part of WildFly Core 3.0.0.Beta16

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3120?page=com.atlassian.jira.plugi... ] Ken Wills reopened WFCORE-3120: ------------------------------- This change was reverted for test flakyness, and needs another look. > Tests broken as part of WildFly Core 3.0.0.Beta16 > ------------------------------------------------- > > Key: WFCORE-3120 > URL: https://issues.jboss.org/browse/WFCORE-3120 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ken Wills > Assignee: Ken Wills > Fix For: 3.0.4.Final > > > These tests were moved to wildfly-core previously. > Tests shown here are going to be ignored or otherwise modified in order to get the core 3.0.0.Beta16 release integrated. > org.jboss.as.test.integration.domain.elytron.SlaveHostControllerElytronAuthenticationTestCase.testSlaveRegistration > org.jboss.as.test.integration.security.perimeter.CLISecurityTestCase.testConnect -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2218) New payload interface

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2218: -------------------------------- OK, so I ran a quick experiment: interface {{Msg}}, abstract class {{DefaultMessage}} and default impl {{BytesMessage}} extending it. The latter is the equivalent of {{Message}} in {{master}}. Performance was the same as master (to be expected) and allocation was: * TLABs: 7.4GB (master: 7.32), allocation rate TLABs: 126.33MB/sec (master: 124.9) * Objects: 33.39GB (master: 37.68), allocation rate: 569.98kB/sec (master: 643.08kB/sec) So we have roughly the same allocation rate in this experiment as in master, and both have a lower allocation rate than JGRP-2218 (see the allocation rates for JGRP-2218 in a previous comment above). > New payload interface > --------------------- > > Key: JGRP-2218 > URL: https://issues.jboss.org/browse/JGRP-2218 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 5.0 > > Attachments: jgrp-2218.jfr, master.jfr > > > h3. Goal > Change payload in {{Message}} from byte[] arrays to a {{Payload}} interface which can have multiple implementations. > h3. Reason > Currently, having to pass a byte[] array to a message leads to unnecessary copying: > * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message > * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}} > * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectPayload}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application. > h3. Design > Instead of copying, the application creates an instance of {{Payload}} and sets the payload in {{Message}}. The {{Payload}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of payload implementations, e.g. > * {{ByteArrayPayload}}: wraps a byte[] array with an offset and length > * {{NioDirectPayload}}: wraps an NIO direct {{ByteBuffer}} > * {{NioHeapPayload}}: wraps an NIO heap-based {{ByteBuffer}} > * {{CompositePayload}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above > * {{IntPayload}}: a single integer > * {{ObjectPayload}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in payloads and they're only marshalled at the end (transport). > * {{PartialPayload}}: a ref to a {{Payload}}, with an offset and length > * {{InputStreamPayload}}: has a ref to an input stream and copies data from input- to output stream when marshalling > The {{Payload}} interface has methods: > * {{size()}} > * {{writeTo(DataOutput)}} > * {{readFrom(DataInput)}} > * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying payload > and possibly also > * {{acquire()}} and > * {{release()}} (for ref-counting) > * {{copy()}} > Each payload impl has an ID and it should be possible to register new impls. A {{PayloadFactory}} maintains a mapping between IDs and impl classes. > When marshalling a {{Payload}}, the ID is written first, followed by the payload's {{writeTo()}} method. When reading payloads, the {{PayloadFactory}} is used to create instances from IDs. > h4. Fragmentation > When fragmenting a buffer, the fragments are instances of {{PartialPayload}} which maintains an offset and length over an underlying payload. When marshalling a {{PartialPayload}}, only the part between offset and offset+length is written to the output stream. > For fragmentation, method {{size()}} is crucial to determine whether a payload needs to be fragmented, or not. If, for example, a payload (e.g. an {{ObjectPayload}}) cannot determine the correct size, it may return {{-1}}. This leads to the {{ObjectPayload}} getting marshalled right away and getting wrapped into a {{ByteArrayPayload}}. So if {{size()}} cannot be determined, we have exactly the same behavior as what's currently done. > h4. Reference counting > If we implement ref-counting, then payloads can be reused as soon as the ref-count is 0. For example, when sending a message, the payload's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the payload cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the payload cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received. > h4. Payload factory > When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{PayloadFactory}} component for a new buffer. A naive implementation might create a new buffer every time, but a more sophisticated one might use a pool of payloads. > The {{PayloadFactory}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of payloads: thus the creation of buffers by the application and of payloads received over the network can be controlled by the same payload management impl. > h4. Symmetry > When sending a {{CompositePayload}} of a 500 byte {{ByteArrayPayload}} and a 1000 byte {{NioDirectPayload}}, would we want to also get the same {{CompositePayload}} consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable? > h4. ObjectPayload > If ObjectPayload cannot determine the size of the serialized data, it should return {{-1}}. This means that {{Message.setPayload(ObjectPayload)}} would right away serialize {{ObjectPayload}} into {{ByteArrayPayload}}. > This means we do have the {{byte[]}} array creation (same as now), but for object payloads which do implement {{size()}} correctly, we could still do late serialization. > h5. ObjectPayload and fragmentation > {{FRAG3}} could decorate {{ObjectPayload}} with a fragmentation payload, which generates fragments on serialization and sends them down the stack. > h4. Misc > * Since this issue includes API changes, the version will be 5.0 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2111) JDK 9 on drools DMN: tests in kie-dmn-core fails on ConcurrentModificationException in KnowledgeBuilderImpl

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2111?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-2111: ---------------------------------- Sprint: 2017 Week 45-46 > JDK 9 on drools DMN: tests in kie-dmn-core fails on ConcurrentModificationException in KnowledgeBuilderImpl > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2111 > URL: https://issues.jboss.org/browse/DROOLS-2111 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.4.1.Final > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > Fix For: 7.5.0.Final > > > When tests from module kie-dmn-core are run on JDK 9, they fails on ConcurrentModificationException with the following stacktrace [1]. > [1] https://gist.github.com/baldimir/92b270fa5527133de8a605c456b136ff -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2111) JDK 9 on drools DMN: tests in kie-dmn-core fails on ConcurrentModificationException in KnowledgeBuilderImpl

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2111?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-2111: ---------------------------------- Fix Version/s: 7.5.0.Final > JDK 9 on drools DMN: tests in kie-dmn-core fails on ConcurrentModificationException in KnowledgeBuilderImpl > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2111 > URL: https://issues.jboss.org/browse/DROOLS-2111 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.4.1.Final > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > Fix For: 7.5.0.Final > > > When tests from module kie-dmn-core are run on JDK 9, they fails on ConcurrentModificationException with the following stacktrace [1]. > [1] https://gist.github.com/baldimir/92b270fa5527133de8a605c456b136ff -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2111) JDK 9 on drools DMN: tests in kie-dmn-core fails on ConcurrentModificationException in KnowledgeBuilderImpl

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2111?page=com.atlassian.jira.plugi... ] Tibor Zimányi reassigned DROOLS-2111: ------------------------------------- Assignee: Tibor Zimányi (was: Matteo Mortari) > JDK 9 on drools DMN: tests in kie-dmn-core fails on ConcurrentModificationException in KnowledgeBuilderImpl > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2111 > URL: https://issues.jboss.org/browse/DROOLS-2111 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.4.1.Final > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > > When tests from module kie-dmn-core are run on JDK 9, they fails on ConcurrentModificationException with the following stacktrace [1]. > [1] https://gist.github.com/baldimir/92b270fa5527133de8a605c456b136ff -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2017