September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1877) System.nanoTime() may be negative

by Bela Ban (JIRA)

Bela Ban created JGRP-1877: ------------------------------ Summary: System.nanoTime() may be negative Key: JGRP-1877 URL: https://issues.jboss.org/browse/JGRP-1877 Project: JGroups Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.5.1, 3.6 According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a negative value. Code like the one below might fail: {code:title=Responses.waitFor()|borderStyle=solid} public boolean waitFor(long timeout) { long wait_time; final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns lock.lock(); try { while(!done && (wait_time=target_time - System.nanoTime()) > 0) { try { cond.await(wait_time,TimeUnit.NANOSECONDS); } catch(InterruptedException e) { } } return done; } finally { lock.unlock(); } } {code} Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a negative value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-905) Arquillian/Remote support

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-905?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed JBJCA-905. --------------------------------- Resolution: Won't Fix > Arquillian/Remote support > ------------------------- > > Key: JBJCA-905 > URL: https://issues.jboss.org/browse/JBJCA-905 > Project: IronJacamar > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Arquillian > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1109) SimpleResourceAdapterRepository fails to convert RA uniqueId to RA name

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1109?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1109. ---------------------------------- Resolution: Deferred > SimpleResourceAdapterRepository fails to convert RA uniqueId to RA name > ----------------------------------------------------------------------- > > Key: JBJCA-1109 > URL: https://issues.jboss.org/browse/JBJCA-1109 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 1.0.21.Final, 1.1.1.Final > Reporter: Ivo Studensky > Assignee: Jesper Pedersen > > SimpleResourceAdapterRepository compares a given ResourceAdapter class with resource adapters from MetadataRepository just by their class names. So if there are 2 separate RAs deployed in the server both with the same ResourceAdapter class (e.g. org.hornetq.ra.HornetQResourceAdapter), it randomly takes one of those and cannot safely distinguish them. > 3 places affected by this: > 1. #getMessageListeners() [1] > 2. #getEnpoint() because of usage of getMDRIdentifier [2] [3] > 3. #getResourceAdapters() [4] > I used a dirty hack to work around this issue which changes API and doesn't fix #3, see [5] + a few changes according to [5] in WF's EJBUtilities. > A possible fix could be to "encode" the RA name into its {{uniqueId}}, so that such a uniqueId would contain RA class name, RA name and eventually a counter (increasing number). > [1] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/or... > [2] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/or... > [3] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/or... > [4] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/or... > [5] https://github.com/istudens/ironjacamar/commit/0f716538ea91e2b547f83f41c6... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-233) Support for non file protocol URL deployments

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-233?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed JBJCA-233. --------------------------------- Resolution: Won't Fix > Support for non file protocol URL deployments > --------------------------------------------- > > Key: JBJCA-233 > URL: https://issues.jboss.org/browse/JBJCA-233 > Project: IronJacamar > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Deployer > Reporter: Aslak Knutsen > Assignee: Jesper Pedersen > Priority: Minor > Attachments: JBJCA-233-Shrinkwrap.patch, JBJCA-233.patch > > > Deployer.deploy(URL) should fully support URL as a deployment unit, not only file:// URLs. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-657) Support javax.sql.XADataSource as connection factory

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-657?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed JBJCA-657. --------------------------------- Resolution: Won't Fix > Support javax.sql.XADataSource as connection factory > ---------------------------------------------------- > > Key: JBJCA-657 > URL: https://issues.jboss.org/browse/JBJCA-657 > Project: IronJacamar > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JDBC > Reporter: Jim Crossley > Assignee: Jesper Pedersen > > For <xa-datasource> definitions, the "wrapper" object returned from JNDI does not implement XADataSource -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-77) Verify OSGi information in all manifests

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-77?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen updated JBJCA-77: --------------------------------- Fix Version/s: (was: 2.0.0.CR1) Priority: Major (was: Blocker) Assignee: (was: Jesper Pedersen) > Verify OSGi information in all manifests > ---------------------------------------- > > Key: JBJCA-77 > URL: https://issues.jboss.org/browse/JBJCA-77 > Project: IronJacamar > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Common, Core, Deployer > Reporter: Jesper Pedersen > > Verify that the OSGi information in all the MANIFEST.MF files are correct. > This information needs to be kept in sync from this point on. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1876) MERGE3 : Strage number and content of subgroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1876: --------------------------- Fix Version/s: 3.6 > MERGE3 : Strage number and content of subgroups > ----------------------------------------------- > > Key: JGRP-1876 > URL: https://issues.jboss.org/browse/JGRP-1876 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.4.2 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Fix For: 3.6 > > Attachments: MergeViewWith210Subgroups.log > > > Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). > The final mergeView is correct and contains 210 members. > Here is an extract of subviews: > {code} > INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] > 210 subgroups > [.... > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] > [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] > ....] > {code} > II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. > Example: > {code} > {A, B, C} => {A, B, C} and {C} => {A, B, C} > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1876) MERGE3 : Strage number and content of subgroups

by Karim AMMOUS (JIRA)

[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ] Karim AMMOUS updated JGRP-1876: ------------------------------- Description: Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). The final mergeView is correct and contains 210 members. Here is an extract of subviews: {code} INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] 210 subgroups [.... [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] ....] {code} II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. Example: {code} {A, B, C} => {A, B, C} and {C} => {A, B, C} {code} was: Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). The final mergeView is correct and contains 210 members. Here is an extract of subviews: {code} INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] 210 subgroups [.... [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] ....] {code} II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. Example: {A, B, C} then {A, B, C} and {C} then {A, B, C} > MERGE3 : Strage number and content of subgroups > ----------------------------------------------- > > Key: JGRP-1876 > URL: https://issues.jboss.org/browse/JGRP-1876 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.4.2 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Attachments: MergeViewWith210Subgroups.log > > > Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). > The final mergeView is correct and contains 210 members. > Here is an extract of subviews: > {code} > INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] > 210 subgroups > [.... > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] > [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] > ....] > {code} > II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. > Example: > {code} > {A, B, C} => {A, B, C} and {C} => {A, B, C} > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1876) MERGE3 : Strage number and content of subgroups

by Karim AMMOUS (JIRA)

[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ] Karim AMMOUS updated JGRP-1876: ------------------------------- Description: Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). The final mergeView is correct and contains 210 members. Here is an extract of subviews: {code} INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] 210 subgroups [.... [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] ....] {code} II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. Example: {A, B, C} then {A, B, C} and {C} then {A, B, C} was: Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). The final mergeView is correct and contains 210 members. Here is an extract of subviews: {code} INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] 210 subgroups [.... [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] ....] {code} II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. Example: {A, B, C} => {A, B, C} and {C} => {A, B, C} > MERGE3 : Strage number and content of subgroups > ----------------------------------------------- > > Key: JGRP-1876 > URL: https://issues.jboss.org/browse/JGRP-1876 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.4.2 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Attachments: MergeViewWith210Subgroups.log > > > Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). > The final mergeView is correct and contains 210 members. > Here is an extract of subviews: > {code} > INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] > 210 subgroups > [.... > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] > [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] > ....] > {code} > II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. > Example: {A, B, C} then {A, B, C} and {C} then {A, B, C} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.... ] Claudio Miranda commented on WFCORE-81: --------------------------------------- Thanks for the input Brian, I will search for other issues. > Expose address of DC as runtime attributes on the HC > ---------------------------------------------------- > > Key: WFCORE-81 > URL: https://issues.jboss.org/browse/WFCORE-81 > Project: WildFly Core > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Heiko Rupp > Labels: rhq > > Currently there is no way to learn about the http management port of the DC from a slave's host.xml or runtime. > 17:02:31] <pilhuhn> I am reading host.xml to find the DC, so that I can contact its http port for e.g. querying the /socket-binding-group if the one on the host is undefined > [17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with adding it as a runtime attribute > [17:04:13] <pilhuhn> bstansberry fine with me when I can query the HC for the http port of the DC > [17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime attribute as well > [17:04:51] <+bstansberry> yes please > [17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime attribute > 17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are going to add alternatives, e.g. a multicast address > [17:06:55] <+bstansberry> so using the config will not be a reliable source; runtime can be -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 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 September 2014