October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-266) KIE resolving dependend artifacts issue

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-266: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1014157 > KIE resolving dependend artifacts issue > --------------------------------------- > > Key: DROOLS-266 > URL: https://issues.jboss.org/browse/DROOLS-266 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR3 > Reporter: Kurt Stam > Assignee: Mario Fusco > Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz > > > This happens when for a dependency the scope is > - set to 'provided' and > - a parameter (in the case ${jbpm.version}) is used in the version field. > So the relevant entry in the pom is: > <dependency> > <groupId>org.drools</groupId> > <artifactId>drools-core</artifactId> > <version>${drools.version}</version> > <scope>provided</scope> > </dependency> > which leads to > 11:15:02,584 WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version} > and then the NPE. I'm guessing the parameter is not being resolved. > 1. it probably should resolve parameters > 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway. > 3. if the dependency cannot be found it should probably stop and not even proceed rather then warn? > 4. it should be interesting to see why it gets the NPE. > If you change the dependency from 'provided' to 'test' things work fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-928) Starting a server with multiple web apps , causes deploymeent failures

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-928?page=com.atlassian.jira.plugin.s... ] Paul Ferraro closed WFLY-928. ----------------------------- Fix Version/s: 8.0.0.Beta1 Resolution: Done Fixed by introduction of GlobalComponentRegistryService. > Starting a server with multiple web apps , causes deploymeent failures > ----------------------------------------------------------------------- > > Key: WFLY-928 > URL: https://issues.jboss.org/browse/WFLY-928 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Shay Matasaro > Assignee: Paul Ferraro > Fix For: 8.0.0.Beta1 > > > When the server starts with multiple web apps , and each one tries to create its cache , the first one locks all other because of a lock on cache manager see ISPN-2898 > this results in deployment failure , and the apps will not get redeployed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1885) ServiceActivator blocks server startup if more than 8 services - platformspecific

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-1885?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-1885. ------------------------------ Resolution: Done Re-closing. Please read previous comment regarding singleton service creation. > ServiceActivator blocks server startup if more than 8 services - platformspecific > --------------------------------------------------------------------------------- > > Key: WFLY-1885 > URL: https://issues.jboss.org/browse/WFLY-1885 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Server > Affects Versions: 8.0.0.Alpha3 > Reporter: Thomas Frühbeck > Assignee: Paul Ferraro > Priority: Minor > Fix For: 8.0.0.Beta1 > > Attachments: stack.log.gz, wildfly-Beta1_blocked_server_on_8_HASingletons.txt.gz > > > We try to start more than 8 services by ServiceActivator. > We follow hasingleton quickstart. > Server startup is blocked on Linux but not on windows (?!?). > If we introduce a delay of e.g. 1 second, all services start correctly also on Linux: > public void activate(ServiceActivatorContext context) { > ESMSSingletonServiceBase<T> service = getSingletonService(); > log.info("ESMSService will be installed: " + service.getSingletonServiceName()); > SingletonService<String> singleton = new SingletonService<String>(service.getSingletonServiceName(), service); > singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry())) > .addDependency(ServerEnvironmentService.SERVICE_NAME, ServerEnvironment.class, service.env) > .setInitialMode(ServiceController.Mode.ACTIVE).install(); > // TODO: diesen Workaround evtl mal beheben. > // (Server startet im Moment nicht anders... zumindest nicht auf Linux! Timingproblem?) > try { > Thread.sleep(1000); > } catch (InterruptedException e) {} > Thread dump of Linux blocked server attached -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2178) exception in distributable webapp leads to infinispan lock contention

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-2178?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-2178. ------------------------------ Resolution: Rejected Fixed by UNDERTOW-107. The lock contention is due to the lock never being released because undertow threw an exception when attempting to trigger the session destroy listener. > exception in distributable webapp leads to infinispan lock contention > ---------------------------------------------------------------------- > > Key: WFLY-2178 > URL: https://issues.jboss.org/browse/WFLY-2178 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Beta1 > Reporter: Thomas Frühbeck > Assignee: Paul Ferraro > Attachments: lockContention_server.log > > > Exception in session.invalidate leads to: > ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-23) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutExceptio > n: Unable to acquire lock after [15 seconds] on key [FIsDATdNvtWFPLx-x-00_6x0] for requestor [GlobalTransaction:<storage/web>:171:local]! Lock held by [GlobalTransaction:<storage/web>:170:local] > server.log attached -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1711: --------------------------- Fix Version/s: 3.4 Radim, I'm busy with 2 other issues. If you submit a pull request by Friday morning, I can get your fix into 3.4, otherwise I'll push it into 3.5. > DELAY2: Do not keep the thread waiting > -------------------------------------- > > Key: JGRP-1711 > URL: https://issues.jboss.org/browse/JGRP-1711 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4 > Reporter: Radim Vansa > Assignee: Bela Ban > Priority: Minor > Fix For: 3.4 > > > Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period. > As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period. > For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers. > Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1711: -------------------------------- I think the reason was that with loopback, messages are copied and sent back up. But you're right: this is done above the transport so the above is moot. > DELAY2: Do not keep the thread waiting > -------------------------------------- > > Key: JGRP-1711 > URL: https://issues.jboss.org/browse/JGRP-1711 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4 > Reporter: Radim Vansa > Assignee: Bela Ban > Priority: Minor > > Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period. > As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period. > For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers. > Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on JGRP-1711: ----------------------------------- As the implementation of incoming messages delay would be more complicated, I think that implementing outcoming delay could be sufficient. Anyway, I can't distinguish where the message got delayed on network. What was the reason to provide both delays in DELAY? > DELAY2: Do not keep the thread waiting > -------------------------------------- > > Key: JGRP-1711 > URL: https://issues.jboss.org/browse/JGRP-1711 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4 > Reporter: Radim Vansa > Assignee: Bela Ban > Priority: Minor > > Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period. > As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period. > For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers. > Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting

by Radim Vansa (JIRA)

Radim Vansa created JGRP-1711: --------------------------------- Summary: DELAY2: Do not keep the thread waiting Key: JGRP-1711 URL: https://issues.jboss.org/browse/JGRP-1711 Project: JGroups Issue Type: Feature Request Affects Versions: 3.4 Reporter: Radim Vansa Assignee: Bela Ban Priority: Minor Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period. As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period. For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers. Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2193) Upgrade javax.json to version 1.0.3

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2193?page=com.atlassian.jira.plugin.... ] Shelly McGowan updated WFLY-2193: --------------------------------- Issue Type: Component Upgrade (was: Feature Request) > Upgrade javax.json to version 1.0.3 > ----------------------------------- > > Key: WFLY-2193 > URL: https://issues.jboss.org/browse/WFLY-2193 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: 8.0.0.CR1 > > > WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1913) CLI 'module add' command fail if a drive letter is specified in its resource path

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.... ] Ivo Studensky edited comment on WFLY-1913 at 10/1/13 10:02 AM: --------------------------------------------------------------- Ah, nevermind, too many context switches on my side. It needs a module add command included in the deploy.scr script. I will enhance the test case accordingly and fix the issue. was (Author: istudens): Ah, nevermind. It needs a module add command included in the deploy.scr script. I will enhance the test case accordingly and fix the issue. > CLI 'module add' command fail if a drive letter is specified in its resource path > --------------------------------------------------------------------------------- > > Key: WFLY-1913 > URL: https://issues.jboss.org/browse/WFLY-1913 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 8.0.0.Alpha4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 8.0.0.Beta1 > > Attachments: install-mojarra-2.0.0.cli > > > If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2013