April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1128) Concurrent call fails when creating container

by Maciej Swiderski (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1128?page=com.atlassian.jira.plugi... ] Maciej Swiderski commented on DROOLS-1128: ------------------------------------------ agree with solution, if complete conversationId cannot be built none should be returned (unless one exists in request) > Concurrent call fails when creating container > --------------------------------------------- > > Key: DROOLS-1128 > URL: https://issues.jboss.org/browse/DROOLS-1128 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Final > Environment: Kie server 6.4.0.Final > Reporter: Karel Suta > Assignee: Karel Suta > Priority: Minor > Labels: reported-by-qe > Attachments: stacktrace.txt > > > If Kie server gets a request concerning container while this container is being created then Kie server throws exception shown in attachment. > It is caused by creating conversation ID header, which contains also release id of container, for any request concerning such container. If container is being created at that moment then release id isn't set yet, causing this issue. > Solution could be to return empty conversation ID(if wasn't set in request) until container is fully initialized - is in started state. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6525) Impossible to use custom FileSystemProviders embedded in an application

by Xavier Dury (JIRA)

Xavier Dury created WFLY-6525: --------------------------------- Summary: Impossible to use custom FileSystemProviders embedded in an application Key: WFLY-6525 URL: https://issues.jboss.org/browse/WFLY-6525 Project: WildFly Issue Type: Bug Components: Class Loading Affects Versions: 10.0.0.Final, 9.0.2.Final Reporter: Xavier Dury Assignee: David Lloyd Using a custom {{FileSystemProvider}} inside an application is not possible with Wildfly: * Using {{Paths.get(uri)}} won't work as {{FileSystemProvider}} caches previously discovered FSPs and won't see those that could be embedded in the application * Using {{FileSystems.newFileSystem(uri, map, classLoader)}} won't work either because FSPs from {{com.sun.nio.*}} will be discovered and those classes are not visible to the application (and are not exported by sun.jdk module.xml). This will give the following error: {{java.util.ServiceConfigurationError: java.nio.file.spi.FileSystemProvider: Provider com.sun.nio.zipfs.ZipFileSystemProvider not found}}. More info on https://developer.jboss.org/message/954528 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1128) Concurrent call fails when creating container

by Karel Suta (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1128?page=com.atlassian.jira.plugi... ] Karel Suta updated DROOLS-1128: ------------------------------- Labels: reported-by-qe (was: ) > Concurrent call fails when creating container > --------------------------------------------- > > Key: DROOLS-1128 > URL: https://issues.jboss.org/browse/DROOLS-1128 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Final > Environment: Kie server 6.4.0.Final > Reporter: Karel Suta > Assignee: Karel Suta > Priority: Minor > Labels: reported-by-qe > Attachments: stacktrace.txt > > > If Kie server gets a request concerning container while this container is being created then Kie server throws exception shown in attachment. > It is caused by creating conversation ID header, which contains also release id of container, for any request concerning such container. If container is being created at that moment then release id isn't set yet, causing this issue. > Solution could be to return empty conversation ID(if wasn't set in request) until container is fully initialized - is in started state. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1128) Concurrent call fails when creating container

by Karel Suta (JIRA)

Karel Suta created DROOLS-1128: ---------------------------------- Summary: Concurrent call fails when creating container Key: DROOLS-1128 URL: https://issues.jboss.org/browse/DROOLS-1128 Project: Drools Issue Type: Bug Components: kie server Affects Versions: 6.4.0.Final Environment: Kie server 6.4.0.Final Reporter: Karel Suta Assignee: Karel Suta Priority: Minor Attachments: stacktrace.txt If Kie server gets a request concerning container while this container is being created then Kie server throws exception shown in attachment. It is caused by creating conversation ID header, which contains also release id of container, for any request concerning such container. If container is being created at that moment then release id isn't set yet, causing this issue. Solution could be to return empty conversation ID(if wasn't set in request) until container is fully initialized - is in started state. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6524) Upgrade Netty to 4.0.33.Final

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-6524?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-4222 to WFLY-6524: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6524 (was: JBEAP-4222) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.CR1) > Upgrade Netty to 4.0.33.Final > ----------------------------- > > Key: WFLY-6524 > URL: https://issues.jboss.org/browse/WFLY-6524 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > Upgrading Netty to 4.0.33 should resolve https://issues.jboss.org/browse/JBEAP-4220 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1127) Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1127?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1127: ------------------------------------- Description: Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself. Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads. *Proposal A)* Add a kieBase configuration property to change the ThreadFactory {code} drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory {code} *Proposal B)* Add a kieBase configuration property to change the ExecutorServiceFactory {code} drools.executorServiceFactory = com.user.project.ExecutorServiceFactory {code} was: Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself. Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads. *Proposal A)* Add a kieBase configuration property to change the ThreadFactory {code} drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory {code} *Proposal B)* Add a kieBase configuration property to change the ExecutorService {code} drools.executorServiceFactory = com.user.project.ExecutorServiceFactory {code} > Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-1127 > URL: https://issues.jboss.org/browse/DROOLS-1127 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself. > Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads. > *Proposal A)* Add a kieBase configuration property to change the ThreadFactory > {code} > drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory > {code} > *Proposal B)* Add a kieBase configuration property to change the ExecutorServiceFactory > {code} > drools.executorServiceFactory = com.user.project.ExecutorServiceFactory > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1127) Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1127?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1127: ------------------------------------- Description: Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself. Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads. Proposal A) Add a kieBase configuration property to change the ThreadFactory {code} drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory {code} Proposal B) Add a kieBase configuration property to change the ExecutorService {code} drools.executorServiceFactory = com.user.project.ExecutorServiceFactory {code} was:We're still investigating, more info coming. > Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-1127 > URL: https://issues.jboss.org/browse/DROOLS-1127 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself. > Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads. > Proposal A) Add a kieBase configuration property to change the ThreadFactory > {code} > drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory > {code} > Proposal B) Add a kieBase configuration property to change the ExecutorService > {code} > drools.executorServiceFactory = com.user.project.ExecutorServiceFactory > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1127) Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1127?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1127: ------------------------------------- Description: Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself. Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads. *Proposal A)* Add a kieBase configuration property to change the ThreadFactory {code} drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory {code} *Proposal B)* Add a kieBase configuration property to change the ExecutorService {code} drools.executorServiceFactory = com.user.project.ExecutorServiceFactory {code} was: Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself. Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads. Proposal A) Add a kieBase configuration property to change the ThreadFactory {code} drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory {code} Proposal B) Add a kieBase configuration property to change the ExecutorService {code} drools.executorServiceFactory = com.user.project.ExecutorServiceFactory {code} > Google App Engine support: Do not call new Thread() by allowing to plug in a custom ThreadFactory > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-1127 > URL: https://issues.jboss.org/browse/DROOLS-1127 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Any code that does `new Thread()` on GAE throws an exception, because you can't create new threads yourself. > Other future cloud platforms might have a similar restriction. It should be possible to plug in a custom way of creating threads. > *Proposal A)* Add a kieBase configuration property to change the ThreadFactory > {code} > drools.threadFactory = com.user.project.GoogleAppEngineThreadFactory > {code} > *Proposal B)* Add a kieBase configuration property to change the ExecutorService > {code} > drools.executorServiceFactory = com.user.project.ExecutorServiceFactory > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2049) Measure round trip time for blocking RPCs via probe

by Bela Ban (JIRA)

Bela Ban created JGRP-2049: ------------------------------ Summary: Measure round trip time for blocking RPCs via probe Key: JGRP-2049 URL: https://issues.jboss.org/browse/JGRP-2049 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.6.10, 4.0 Currently, RPC RTT is measured at the {{RpcDispatcher}} level. The current code doesn't measure blocking RPCs which return a future. Moving this code to the {{RequestCorrelator}} level would allow us to measure RTTs for this as well, as an RPC is terminated via {{done()}} or {{cancel()}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2048) ClassConfigurator: use constructors rather than Classes in map

by Bela Ban (JIRA)

Bela Ban created JGRP-2048: ------------------------------ Summary: ClassConfigurator: use constructors rather than Classes in map Key: JGRP-2048 URL: https://issues.jboss.org/browse/JGRP-2048 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 4.0 Investigate whether use of {{Constructor}} as values in the maps rather than {{Class<?>}} improves performance. {{Class.newInstance()}} does cache the constructor, but there's a security check that's executed once, so using the constructor may improve perf. Also, if a class doesn't have an empty constructor, using {{Class.newInstance()}} would throw an exception, whereas using constructors would detect this at load time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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