January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1565) new config to defer TCP client socket binding

by William DeCoste (JIRA)

[ https://issues.jboss.org/browse/JGRP-1565?page=com.atlassian.jira.plugin.... ] William DeCoste resolved JGRP-1565. ----------------------------------- Resolution: Done This was actually resolved in 3.0.16 > new config to defer TCP client socket binding > --------------------------------------------- > > Key: JGRP-1565 > URL: https://issues.jboss.org/browse/JGRP-1565 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.0.9 > Reporter: William DeCoste > Assignee: William DeCoste > Fix For: 3.0.15 > > > OpenShift issue with clustering between Nodes -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-965) Support InvalidIdleConnections and AllInvalidIdleConnections for flush strategy

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-965: ------------------------------------- Summary: Support InvalidIdleConnections and AllInvalidIdleConnections for flush strategy Key: JBJCA-965 URL: https://issues.jboss.org/browse/JBJCA-965 Project: IronJacamar Issue Type: Task Components: Common, Core Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.1.0.Beta4 -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-964) Include original exception in getConnection() trace

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-964?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed JBJCA-964. --------------------------------- Fix Version/s: (was: 1.1.0.Beta4) (was: 1.0.15.Final) Resolution: Rejected > Include original exception in getConnection() trace > --------------------------------------------------- > > Key: JBJCA-964 > URL: https://issues.jboss.org/browse/JBJCA-964 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.0.14.Final, 1.1.0.Beta3 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-964) Include original exception in getConnection() trace

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-964: ------------------------------------- Summary: Include original exception in getConnection() trace Key: JBJCA-964 URL: https://issues.jboss.org/browse/JBJCA-964 Project: IronJacamar Issue Type: Bug Components: JDBC Affects Versions: 1.1.0.Beta3, 1.0.14.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.15.Final, 1.1.0.Beta4 -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1563) UNICAST2: first-message-lost problem

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1563?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1563: -------------------------------- The resending can be integrated with the retransmit task: in addition to asking for missing messages, the retransmit task also checks all SenderEntry elements and sees if the ack for the first message has been received. If not, it resends the first message. This way, we don't need another task to run in the timer. > UNICAST2: first-message-lost problem > ------------------------------------ > > Key: JGRP-1563 > URL: https://issues.jboss.org/browse/JGRP-1563 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.2.6, 3.3 > > > If A sends its first message A#1 to B, but the network drops A#1, B won't be able to receive A#1 unless A sends another message. > Even the stable task won't help: as B only sends stable messages to connected members (and A isn't), it will never send a stable message to A. > SOLUTION: > - Use acking for the first message > - Continue sending the first message until it has been acked, or a configurable time period has elapsed > - Note that we cannot cancel this task based on *membership* (view changes), as unicast messages can be sent to members outside of our view -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6338) Remove -jaxpmodule from start scripts

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6338?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6338: --------------------------------------- David, in chat you mentioned SPI files, but I have no idea what you mean. :) I thought I'd understand by looking at the modules and seeing what's there, but I don't see anything. > Remove -jaxpmodule from start scripts > ------------------------------------- > > Key: AS7-6338 > URL: https://issues.jboss.org/browse/AS7-6338 > Project: Application Server 7 > Issue Type: Task > Components: Scripts > Reporter: David Lloyd > Assignee: Brian Stansberry > Priority: Minor > Fix For: 7.2.0.Alpha1 > > > JBoss Modules uses SPI to locate the JAXP providers, since 1.1. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6338) Remove -jaxpmodule from start scripts

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6338?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6338: ---------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.3.0.Alpha1) Scheduling for 7.2. It's no big deal if this drops, but we are going to make some boot changes so might as well try to clean up stuff like this while we are at it. > Remove -jaxpmodule from start scripts > ------------------------------------- > > Key: AS7-6338 > URL: https://issues.jboss.org/browse/AS7-6338 > Project: Application Server 7 > Issue Type: Task > Components: Scripts > Reporter: David Lloyd > Assignee: Brian Stansberry > Priority: Minor > Fix For: 7.2.0.Alpha1 > > > JBoss Modules uses SPI to locate the JAXP providers, since 1.1. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-3524) HostControllerConnectionService connection timeout is not configurable

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-3524?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-3524: ---------------------------------- Issue Type: Enhancement (was: Bug) > HostControllerConnectionService connection timeout is not configurable > ---------------------------------------------------------------------- > > Key: AS7-3524 > URL: https://issues.jboss.org/browse/AS7-3524 > Project: Application Server 7 > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 7.1.0.Final > Reporter: Dominik Pospisil > Assignee: Bartosz Baranowski > Fix For: 7.3.0.Alpha1 > > > I am seeing intermittent failures when starting AS7 in domain mode. It seems that this is due to HostControllerConnectionService has hardcoded 15s timeout when trying to connect to DC. I think that this value should be configurable. > HostControllerConnectionService.java: > ... > ProtocolChannelClient.Configuration configuration = new ProtocolChannelClient.Configuration(); > configuration.setEndpoint(endpointInjector.getValue()); > configuration.setConnectionTimeout(15000); > configuration.setUri(new URI("remote://" + hcAddressInjector.getValue().getHostName() + ":" + hcAddressInjector.getValue().getPort())); > client = ProtocolChannelClient.create(configuration); > ... > Exception I am getting: > [Server:server-two] 13:52:54,766 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.host.controller.channel: org.jboss.msc.service.StartException in service jboss.host.controller.channel: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost.localdomain:9999. The connection timed out > [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:103) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT] > [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] > [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] > [Server:server-two] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22] > [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22] > [Server:server-two] at java.lang.Thread.run(Thread.java:679) [:1.6.0_22] > [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost.localdomain:9999. The connection timed out > [Server:server-two] at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:166) [jboss-as-protocol-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT] -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-5897) Allow user applications to introduce server side non-EE interceptors for EE invocations

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/AS7-5897?page=com.atlassian.jira.plugin.s... ] jaikiran pai edited comment on AS7-5897 at 1/16/13 10:21 AM: ------------------------------------------------------------- Here's the documentation for this feature https://docs.jboss.org/author/display/AS72/Container+interceptors was (Author: jaikiran): Here the documentation for this feature https://docs.jboss.org/author/display/AS72/Container+interceptors > Allow user applications to introduce server side non-EE interceptors for EE invocations > --------------------------------------------------------------------------------------- > > Key: AS7-5897 > URL: https://issues.jboss.org/browse/AS7-5897 > Project: Application Server 7 > Issue Type: Feature Request > Components: EE, EJB > Affects Versions: 7.1.3.Final (EAP) > Reporter: jaikiran pai > Assignee: jaikiran pai > Fix For: 7.2.0.Alpha1 > > > One of the topics that we discussed in the AS meeting was the use case where users have been demanding for a way to run their application specific interceptors before some of the server side app server specific interceptors and user application specific EE interceptors are run. This will allow for the user applications to have a way to pass in additional information (like security related info) to the server side interceptors (like the security interceptor) so that the information can then be made use for deciding whether or not the call should be allowed to happen or not. We used to allow to do this in previous versions of a AS via AOP but there's no current way to do it in AS7. The EE interceptors come into picture too late. > Some approaches have been discussed around this, during the meeting, with the goal that whatever approach we introduce should be something that we should be able to "support" for a long time without having to ask the users to migrate to a newer way of doing this, in every other major release: > 1) Allow the interceptors to use jboss-invocation library to use the interceptor API and implement their interceptors. The advantage of this approach as compared with the other approaches below, is that the semantics of this interceptor interface is something that "we" can decide and wouldn't matter if it conflicts with the semantics of the EE specific interceptors (for ex: EE specific interceptors have a invocationCtx.getTarget() which won't make sense for server side interceptors which are being invoked *before* the application component has been created) > 2) Allow the user applications to just use the EE interceptor API for these intereceptors and we explicitly state that certain APIs like invocationCtx.getTarget() will have different semantics when run as a "system interceptor" > 3) Introduce a very small/tiny API (EarlyEEInvocationContext as David calls it :)) which exposes limited semantics that the interceptors can rely on. > We are leaning more towards #2 since that wouldn't need any new library or API for these interceptors, but would only require an explicit documentation of what's allowed and what's not in such interceptors. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-53) Add a BootRotatingFileHandler

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-53?page=com.atlassian.jira.plugin.... ] David Lloyd updated LOGMGR-53: ------------------------------ Fix Version/s: 1.4.0.Beta3 (was: 1.4.0.Beta2) > Add a BootRotatingFileHandler > ----------------------------- > > Key: LOGMGR-53 > URL: https://issues.jboss.org/browse/LOGMGR-53 > Project: JBoss Log Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: core > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.4.0.Beta3 > > > Add a BootRotatingFileHandler. -- 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

13 years, 3 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 January 2013