January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1050) Fix JGroups pom file and make JGroups OSGi compliant

by Bulat Nigmatullin (JIRA)

Fix JGroups pom file and make JGroups OSGi compliant ---------------------------------------------------- Key: JGRP-1050 URL: https://jira.jboss.org/jira/browse/JGRP-1050 Project: JGroups Issue Type: Patch Reporter: Bulat Nigmatullin Assignee: Bela Ban Priority: Optional 1. Fix Maven build script, so it will produce the same result as ant build script. 2. Make Maven produced jar's to contain MANIFEST.MF with OSGi info. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

6
17
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1838) Improve DataSource retry mechanism

by Yong Hao Gao (JIRA)

Improve DataSource retry mechanism ---------------------------------- Key: JBMESSAGING-1838 URL: https://issues.jboss.org/browse/JBMESSAGING-1838 Project: JBoss Messaging Issue Type: Feature Request Components: Messaging Core Persistence Affects Versions: 1.4.7.GA, 1.4.0.SP3.CP11 Reporter: Yong Hao Gao Assignee: Yong Hao Gao Fix For: 1.4.0.SP3.CP12, 1.4.8.GA Currently JBM will retry max 25 times for a non connection failure. That's not good enough when a DB is disconnected and reconnected after max retry has reached. JBM will be in a 'failure' state and requires a re-start of the node. If we allow user to configure the retry until the DB connection is back, JBM can work on without restart. We can also enable retry on connection failure too. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
6
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1822) MessageSucker failures cause the delivery of the failed message to stall

by david.boeren (JIRA)

MessageSucker failures cause the delivery of the failed message to stall ------------------------------------------------------------------------ Key: JBMESSAGING-1822 URL: https://jira.jboss.org/browse/JBMESSAGING-1822 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.6.GA Reporter: david.boeren Fix For: Unscheduled Attachments: helloworld.zip The MessageSucker is responsible for migrating messages between different members of a cluster, it is a consumer to the remote queue from which it receives messages destined for the queue on the local cluster member. The onMessage routine, at its most basic, does the following - bookkeeping for the incoming message, including expiry - acknowledge the incoming message - attempt to deliver to the local queue When the delivery fails, the result is the *appearance* of lost messages. Those messages which are processed during the failure are not redelivered, but they still exist in the database. The only way I have found to trigger the redelivery of those messages is to redeploy the queue containing the messages and/or restart that app server. Obviously neither approach is acceptable. In order to trigger the error I created a SOA cluster which *only* shared the JMS database, and no other. I modified the helloworld quickstart to display a counter of messages consumed, clustered the *esb* queue, and then used byteman to trigger the faults. The byteman rule is as follows, the quickstart will be attached. RULE throw every fifth send INTERFACE ProducerDelegate METHOD send AT ENTRY IF callerEquals("MessageSucker.onMessage", true) && (incrementCounter("throwException") % 5 == 0) DO THROW new IllegalStateException("Deliberate exception") ENDRULE This results in an exception being thrown for every fifth message. Once the delivery has quiesced, examine the JBM_MSG and JBM_MSG_REF tables to see the messages which have not been delivered. The clusters are ports-default and ports-01, the client seeds the gateway by sending 300 messages to the default. Adding up the counter from each server *plus* the message count from JBM_MSG results in 300 (or multiples thereof for more executions). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

5
35
0 / 0

[JBoss JIRA] Created: (JBMETA-328) Resource injection validation against interfaces

by John Ament (JIRA)

Resource injection validation against interfaces ------------------------------------------------ Key: JBMETA-328 URL: https://issues.jboss.org/browse/JBMETA-328 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Reporter: John Ament When you have an interface without an implementation, jboss is attempting to validate an injection point that should not exist. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1846) The default datachanneludpport cannot be changed

by Tyronne Wickramarathne (JIRA)

The default datachanneludpport cannot be changed ------------------------------------------------ Key: JBMESSAGING-1846 URL: https://issues.jboss.org/browse/JBMESSAGING-1846 Project: JBoss Messaging Issue Type: Bug Components: JMS Clustering Affects Versions: 1.4.7.GA Environment: JBoss-EAP-5.1.0 , JBM-1.4.7 Reporter: Tyronne Wickramarathne The default datachanneludpport cannot be changed via jgroups-channelfactory-stacks.xml configuration file -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBWEB-164) Allow expression language in server config files

by Shaun Appleton (JIRA)

Allow expression language in server config files ------------------------------------------------ Key: JBWEB-164 URL: https://jira.jboss.org/jira/browse/JBWEB-164 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tomcat Reporter: Shaun Appleton Assignee: Remy Maucherat Allow expression language like that shown in http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/4.... to be used in server config files for example server.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (JBREM-1263) ClientSocketWrapper.checkConnection() should check returned value

by Ron Sigal (JIRA)

ClientSocketWrapper.checkConnection() should check returned value ----------------------------------------------------------------- Key: JBREM-1263 URL: https://issues.jboss.org/browse/JBREM-1263 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3.SP3, 2.5.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.3.SP2, 2.2.3.SP4 The old and new connection checking tests used by org.jboss.remoting.transport.socket.ClientSocketWrapper and ServerSocketWrapper interact in a negative way. In the old test, turned on when socket.check_connection is set to true, ClientSocketWrapper sends a 1, ServerSocketWrapper returns it, and if ClientSocketWrapper is able to read a byte, the test passes. But in the new test, ServerSocketWrapper writes two 254 bytes as it is closing. If ClientSocketWrapper is doing the old test and it reads one of these bytes, it thinks the test has passed. It should check for the actual value of the returned byte. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-1246) Can't authenticate using TransporterClient

by Sebastian Dietrich (JIRA)

Can't authenticate using TransporterClient ------------------------------------------ Key: JBREM-1246 URL: https://jira.jboss.org/browse/JBREM-1246 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.2.SP3 (Flounder) Reporter: Sebastian Dietrich I'd like to introduce basic authentication in my project which uses TransporterClient to connect to the server. According to the documentation (http://docs.jboss.org/jbossremoting/2.5.3.SP1/html_single/#d0e2251 5.4.11. HTTP(S) Client Invoker - proxy and basic authentication) this is not supported with TransporterClient, but only via response = client.invoke(payload, metadata); TransporterClient uses response = remotingClient.invoke(request); (see TransporterClient.class Line 321) Unfortunately I can neither subclass TransporterClient (since its constructors are private) nor decorate it (since its invoke method I'd like to change uses private attributes & methods). ==> Please provide a way to use basic authentication in TransporterClient This could be done easily via a further constructor/factory method which accepts metadata. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-1245) Consider javax.net.ssl.SSLException("Connection has been shutdown")

by Ron Sigal (JIRA)

Consider javax.net.ssl.SSLException("Connection has been shutdown") ------------------------------------------------------------------- Key: JBREM-1245 URL: https://jira.jboss.org/browse/JBREM-1245 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.3.SP1, 2.2.3.SP3 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP3, 2.2.3.SP4 An SSLSocket whose remote counterpart has closed will throw javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Software caused connection abort: socket write error This should be considered a retriable exception, but the RETRIABLE_ERROR_MESSAGE regular expression in org.jboss.remoting.transport.MicroSocketClientInvoker doesn't match it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-1238) Need invocation timeouts in synchronized blocks in MicroRemoteClientInvoker that create and terminate leases

by Ron Sigal (JIRA)

Need invocation timeouts in synchronized blocks in MicroRemoteClientInvoker that create and terminate leases ------------------------------------------------------------------------------------------------------------- Key: JBREM-1238 URL: https://jira.jboss.org/browse/JBREM-1238 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP2 (Flounder) org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network invocations inside synchronized blocks, and, if the invocations get hung up, then it becomes impossible to create new connections with leasing enabled. Setting the 'timeout" parameter appropriately would work around the problem, but some users, notably JBossMessaging, set "timeout" to 0. A speclal case timeout parameter should be used, along with the per invocation timeout facility, to prevent MicroRemoteClientInvoker from getting stuck in establishLease() or terminateLease(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2011