January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-890) Fix thread pool eviction in socket transport

by Ron Sigal (JIRA)

Fix thread pool eviction in socket transport -------------------------------------------- Key: JBREM-890 URL: http://jira.jboss.com/jira/browse/JBREM-890 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP4, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Currently org.jboss.rermoting.transport.socket.ServerThread.evict() attempts to interrupt a thread blocked on i/o in acknowledge() or readVersion() and return it to SocketServerInvoker.threadpool where it can be reused. However, interrupt() will not normally unblock a thread in an i/o call. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-891) ConnectionValidator should report if lease has expired

by Ron Sigal (JIRA)

ConnectionValidator should report if lease has expired ------------------------------------------------------ Key: JBREM-891 URL: http://jira.jboss.com/jira/browse/JBREM-891 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP4 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Clebert Suconic wrote: > You have this scenario: > > - Client is paused for 1 minute (say... a huge GC for example) > - Server will invalidate that client (and close server side's objects) > - Client comes back alive... it will then resume pings... > - Nothing will invalidate the client, and the client became isolated). Reply: This isn't a Remoting bug. What you have described is Remoting behaving correctly, according to the current design. 1. On the server side, the lease mechanism can inform the application that the client is "unavailable". 2. On the client side, the ConnectionValidator can inform the application that the server is "unavailable". One side or the other could be unavailable either because (1) it died or because (2) the network isn't functioning. In the first case, it doesn't make sense for one side to inform the other side of the failure, because there's no one on the other side to talk to. In the second case, both sides should see and report the same failure. In the scenario you've described, the client isn't really unavailable - the apparent failure is just a timing artifact. The solution is to change the timing. I.e., extend the lease period. Proposal: If leasing is enabled on the server side, org.jboss.remoting.ServerInvoker, which responding to a PING from org.jboss.remoting.ConnectionValidator, should indicate if the lease is still alive. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-895) MicroSocketClientInvoker.transport() must check for timeout after invocation attempt.

by Ron Sigal (JIRA)

MicroSocketClientInvoker.transport() must check for timeout after invocation attempt. ------------------------------------------------------------------------------------- Key: JBREM-895 URL: http://jira.jboss.com/jira/browse/JBREM-895 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP4 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Unit test org.jboss.test.remoting.callback.pull.CallbackPollerShutdownTestCase revealed a bug in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(). After the invocation attempt loop, there is a test to see if numberOfCallRetries has been exceeded. If so, the semaphore has already been released, and an exception is thrown. Another way the loop could end unsuccessfully is if a per invocation timeout has occurred. Currently, there is no test for this condition, so that semaphore.release() is called again, increasing the semaphore counter incorrectly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1437) DOT notation gives an error

by Toni Rikkola (JIRA)

DOT notation gives an error --------------------------- Key: JBRULES-1437 URL: http://jira.jboss.com/jira/browse/JBRULES-1437 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.4 Reporter: Toni Rikkola Following rule gave an java.lang.ClassCastException: org.drools.analytics.report.components.RedundancyShadowProxy cannot be cast to org.drools.analytics.components.RulePossibility exeption. The bug was found when creating subsumption rules for analytics. rule "Find subsumptant rule possibilities" when $redundancy :Redundancy( left.causeType == CauseType.RULE, $leftRuleId :left.id, $rightRuleId :right.id ) # Find two RulePossibilities. $rp1 :RulePossibility( ruleId == $leftRuleId ) $rp2 :RulePossibility( ruleId == $rightRuleId ) # For every pattern possibility in $rp1 there is a redundant pattern possibility in $rp2. forall( $pp :PatternPossibility( ruleId == $rp1.ruleId, this memberOf $rp1.items ) ) exists( Subsumption( ) or Redundancy( ) ) then System.out.println("pim"); end First tought that this was caused by or operator in exists, but tirelli found out that it is caused by a DOT notation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-5175) The profile service bootstrap should undeploy in reverse deployment phase order

by Adrian Brock (JIRA)

The profile service bootstrap should undeploy in reverse deployment phase order ------------------------------------------------------------------------------- Key: JBAS-5175 URL: http://jira.jboss.com/jira/browse/JBAS-5175 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ProfileService Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.Beta4 The profile service bootstrap should undeploy in reverse deployment phase order. i.e. undeploy APPLICATIONS then DEPLOYERS then BOOTSTRAP -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBXB-118) switch to MC's ClassInfo.getComponentType()

by Alexey Loubyansky (JIRA)

switch to MC's ClassInfo.getComponentType() ------------------------------------------- Key: JBXB-118 URL: http://jira.jboss.com/jira/browse/JBXB-118 Project: JBoss XML Binding (JBossXB) Issue Type: Task Affects Versions: JBossXB-2.0.0.CR5 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky Fix For: JBossXB-2.0.0.CR6 Currently, JBossXB builder uses its own methods to find the type of a collection type. It should use the ClassInfo API instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1074) Support the use of Integer, Float, Short and Byte in accumulate functions

by Geoffrey De Smet (JIRA)

Support the use of Integer, Float, Short and Byte in accumulate functions ------------------------------------------------------------------------- Key: JBRULES-1074 URL: http://jira.jboss.com/jira/browse/JBRULES-1074 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.GA Reporter: Geoffrey De Smet Assigned To: Edson Tirelli Priority: Minor Fix For: 4.0.1 Currently, even if everything is an Integer (or int's) a value still gets supplied as a Long. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-673) Can't create a second version of a shared transport channel

by Brian Stansberry (JIRA)

Can't create a second version of a shared transport channel ----------------------------------------------------------- Key: JGRP-673 URL: http://jira.jboss.com/jira/browse/JGRP-673 Project: JGroups Issue Type: Bug Reporter: Brian Stansberry Assigned To: Bela Ban SharedTransportTest.testReCreationWithSurvivingChannel() shows the problem: // Create 2 channels sharing a transport a=createSharedChannel(SINGLETON_1); a.connect("A"); b=createSharedChannel(SINGLETON_1); b.connect("B"); a.disconnect(); // a is disconnected so we should be able to create a new // channel with group "A" c=createSharedChannel(SINGLETON_1); c.connect("A"); This is basically testing a scenario where a service that creates/connects a channel is restarted. This works fine if the 'b' channel isn't connected. AFAICT, problem is Configurator.startProtocolStack() is storing data in the TP.up_prots map, but the disconnect() process (e.g. Configurator.stopProtocolStack()) isn't removing it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-675) Shared transport: registered channel is not correctly unregistered on disconnect()

by Bela Ban (JIRA)

Shared transport: registered channel is not correctly unregistered on disconnect() ---------------------------------------------------------------------------------- Key: JGRP-675 URL: http://jira.jboss.com/jira/browse/JGRP-675 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6.2, 2.7 When a channel on a shared transport T connects to A, disconnects and reconnects, there is an exception because A was not removed from T's up_prots hashmap. SharedTransportTest.testReCreationWithSurvivingChannel() reproduces the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBAS-2517) Upgrade packaged commons-collections from 2.1 to 3.1

by Kenny MacLeod (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2517?page=all ] Kenny MacLeod closed JBAS-2517. ------------------------------- Resolution: Done > Upgrade packaged commons-collections from 2.1 to 3.1 > ---------------------------------------------------- > > Key: JBAS-2517 > URL: http://jira.jboss.com/jira/browse/JBAS-2517 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Other > Affects Versions: JBossAS-4.0.3 Final > Reporter: Kenny MacLeod > > The default and all configurations of 4.0.3 come packaged with commons-collections 2.1 > This should be upgraded to 3.1 (or whatever the latest and greatest is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 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 January 2008