March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1094) OptaPlanner Kie server service: unable to retrieve best solution

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1094?page=com.atlassian.jira.plugi... ] Geoffrey De Smet resolved DROOLS-1094. -------------------------------------- Fix Version/s: 6.4.0.Final 7.0.0.Final Resolution: Done Fixed > OptaPlanner Kie server service: unable to retrieve best solution > ---------------------------------------------------------------- > > Key: DROOLS-1094 > URL: https://issues.jboss.org/browse/DROOLS-1094 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.CR1 > Environment: Kie server OptaPlanner service > Reporter: Karel Suta > Assignee: Geoffrey De Smet > Labels: qe-recommend-fix-before-ga, reported-by-qe > Fix For: 6.4.0.Final, 7.0.0.Final > > > When I try to retrieve best solution from Solver in Kie server OptaPlanner extension, JAXB and XSTREAM works correctly but JSON doesn't. JSON marshalling isn't able to map planning variable in planning entity. > It can be simulated using cloudbalance problem which is part of Kie server OptaPlanner integration tests. See test method testGetBestSolution in OptaplannerIntegrationTest. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-6420: ------------------------------ Attachment: artemis-hornetq-client.tgz Updated example working with WildFly 10.1.0.Final-SNAPSHOT > 30secs delay on consumer.receive() in spite of shorter timeout > -------------------------------------------------------------- > > Key: WFLY-6420 > URL: https://issues.jboss.org/browse/WFLY-6420 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Tomohisa igarashi > Assignee: Jeff Mesnil > Fix For: 10.1.0.Final > > Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz > > > consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases. > The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-6420: ----------------------------------- Your dependencies were not correct. You should use org.wildfly:wildfly-jms-client-bom to get the correct ones. Please find attached your project with a correct POM (and updated code for JMS 2.0). I've tested it against WildFly master and it works (even after restarting the server) > 30secs delay on consumer.receive() in spite of shorter timeout > -------------------------------------------------------------- > > Key: WFLY-6420 > URL: https://issues.jboss.org/browse/WFLY-6420 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Tomohisa igarashi > Assignee: Jeff Mesnil > Fix For: 10.1.0.Final > > Attachments: artemis-hornetq-client.tgz > > > consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases. > The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout

by Tomohisa igarashi (JIRA)

[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ] Tomohisa igarashi commented on WFLY-6420: ----------------------------------------- Ah thanks for catching it, but it still reproduces with specifying 1.1.0.wildfly-014 in the POM here. > 30secs delay on consumer.receive() in spite of shorter timeout > -------------------------------------------------------------- > > Key: WFLY-6420 > URL: https://issues.jboss.org/browse/WFLY-6420 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Tomohisa igarashi > Assignee: Jeff Mesnil > Fix For: 10.1.0.Final > > Attachments: artemis-hornetq-client.tgz > > > consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases. > The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6424) Update README-EJB-JMS.txt file in bin/client directory

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-6424: --------------------------------- Summary: Update README-EJB-JMS.txt file in bin/client directory Key: WFLY-6424 URL: https://issues.jboss.org/browse/WFLY-6424 Project: WildFly Issue Type: Bug Affects Versions: 10.0.0.Final Reporter: Jeff Mesnil Assignee: Jason Greene Priority: Minor The file reference the BOMs org.jboss.as:jboss-as-ejb-client-bom and org.jboss.as:jboss-as-jms-client-bom which have been moved to the org.wildfly namespace -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6424) Update README-EJB-JMS.txt file in bin/client directory

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-6424?page=com.atlassian.jira.plugin.... ] Jeff Mesnil reassigned WFLY-6424: --------------------------------- Assignee: Jeff Mesnil (was: Jason Greene) > Update README-EJB-JMS.txt file in bin/client directory > ------------------------------------------------------ > > Key: WFLY-6424 > URL: https://issues.jboss.org/browse/WFLY-6424 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > > The file reference the BOMs org.jboss.as:jboss-as-ejb-client-bom and org.jboss.as:jboss-as-jms-client-bom which have been moved to the org.wildfly namespace -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-6420: ----------------------------------- I see that in your example you are using Artemis 1.2.0. WildFly is using Artemis 1.1.0.wildlfy-014 and I'm not sure how it is compatible with 1.2.0. We recommend to use the BOM that contains sanctioned version for JMS client: org.wildfly:wildfly-jms-client-bom > 30secs delay on consumer.receive() in spite of shorter timeout > -------------------------------------------------------------- > > Key: WFLY-6420 > URL: https://issues.jboss.org/browse/WFLY-6420 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Tomohisa igarashi > Assignee: Jeff Mesnil > Fix For: 10.1.0.Final > > Attachments: artemis-hornetq-client.tgz > > > consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases. > The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-472) When key protection password is not defined us the one for store protection

by Peter Skopek (JIRA)

Peter Skopek created ELY-472: -------------------------------- Summary: When key protection password is not defined us the one for store protection Key: ELY-472 URL: https://issues.jboss.org/browse/ELY-472 Project: WildFly Elytron Issue Type: Bug Components: Credential Store Reporter: Peter Skopek Assignee: Peter Skopek KeystorePasswordStore fails to store secret when "key.password" option is not specified. Fix will use "store.password" as default in case key.password is empty. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-471) KeystorePasswordStore leaves empty file when store operation fails of newly created store

by Peter Skopek (JIRA)

Peter Skopek created ELY-471: -------------------------------- Summary: KeystorePasswordStore leaves empty file when store operation fails of newly created store Key: ELY-471 URL: https://issues.jboss.org/browse/ELY-471 Project: WildFly Elytron Issue Type: Bug Components: Credential Store Reporter: Peter Skopek Assignee: Peter Skopek KeystorePasswordStore creates empty file when automatically created from subsystem and subsequent "store the secret" operation fails. Next time the subsystem tries to add the same store (the same store file) it fails. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2033) Replace Java serialization with JGroups marshalling

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2033?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2033: -------------------------------- Marshaller now only marshals _arguments_ to RPC calls and _return values_, not {{MethodCalls}}. In addition, there's an {{estimatedSize()}} call which is called before serialization to compute a size for the output stream that prevents resizing of its underlying buffer. > Replace Java serialization with JGroups marshalling > --------------------------------------------------- > > Key: JGRP-2033 > URL: https://issues.jboss.org/browse/JGRP-2033 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.9, 4.0 > > > In some cases, even JGroups internal code still uses Java serialization. Replace this with marshalling (using {{Streamable}}). Analysis of all occurrences of {{Util.objectFromXXX()}} calls. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 March 2016