November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-675) Problems with Servlet invoker

by Tom Elrod (JIRA)

Problems with Servlet invoker ----------------------------- Key: JBREM-675 URL: http://jira.jboss.com/jira/browse/JBREM-675 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 1.4.6.GA, 2.0.0.GA (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Attachments: ServletServerInvoker.java Several problems with servlet invoker: 1) There can't be two servlet invokers (it's necessary, for example, if you want to use them for JBoss Messagning and for EJBs - they require separate connectors) because ObjectName is hard-coded in ServletServerInvoker.java 2) Null returns from invokers are sent to client as empty 204 responses and custom marshallers have no change to process return value. This breaks JBoss Messaging which expects that EVERY message contains at least two bytes (version tag and format tag). -- 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

17 years, 2 months

2
8
0 / 0

[JBoss JIRA] Created: (JBREM-838) allow user to set content-type for http responses (part 2: ServletServerInvoker)

by Ron Sigal (JIRA)

allow user to set content-type for http responses (part 2: ServletServerInvoker) -------------------------------------------------------------------------------- Key: JBREM-838 URL: http://jira.jboss.com/jira/browse/JBREM-838 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.2.GA Reporter: Tom Elrod Assigned To: Ron Sigal Fix For: 2.2.2.SP1 Currently the CoyoteInvoker.versionedWrite() method will set the content type of the http response by using WebUtil.getContentType(responseObject) to identify the content type based on the response object type being sent back to client. Should allow this to be overriden by the user in the same way the response code/message can be (using the response map). -- 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

17 years, 2 months

1
3
0 / 0

[JBoss JIRA] Closed: (JBREM-475) Eliminate ShutdownRequestThread in MultiplexingManager.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-475?page=all ] Ron Sigal closed JBREM-475. --------------------------- Resolution: Won't Fix See JBREM-842 "Deprecate multiplex transport". > Eliminate ShutdownRequestThread in MultiplexingManager. > ------------------------------------------------------- > > Key: JBREM-475 > URL: http://jira.jboss.com/jira/browse/JBREM-475 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.Beta1 (Pinto) > > > When a MultiplexingManager is requesting permission from its remote counterpart to shut down, it periodically creates a ShutdownRequestThread to send a request permission message and wait for a response. It shoud be possible to handle the waiting on the pending action thread. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1207) Investigate failures in StateTransferUnderLoadTest

by Manik Surtani (JIRA)

Investigate failures in StateTransferUnderLoadTest -------------------------------------------------- Key: JBCACHE-1207 URL: http://jira.jboss.com/jira/browse/JBCACHE-1207 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Vladimir Blagojevic Fix For: 2.1.0.GA This involves attempting to transfer state while having several concurrent put operations that *seem* to result in: 1) A block being issued 2) The put operation holding locks on the state generator 3) The put not being able to complete because of the block 4) The state transfer not being able to generate state because of the put operation 5) Deadlock! -- 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

17 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-615) UDP: JGroups always allocates the same ports

by Bela Ban (JIRA)

UDP: JGroups always allocates the same ports -------------------------------------------- Key: JGRP-615 URL: http://jira.jboss.com/jira/browse/JGRP-615 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5.2, 2.6 In 2.5 and 2.6, JGroups always allocates the same ports with UDP and no bind_port set. This is different from 2.4, where different (increasing) ports were used. Investigate why this is the case, and what changed between 2.4 and 2.5. This doesn't happen on Windows and macOS, just on Linux. -- 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

17 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4689) Upgrade JBoss messaging to 1.4.0.GA

by Dimitris Andreadis (JIRA)

Upgrade JBoss messaging to 1.4.0.GA ----------------------------------- Key: JBAS-4689 URL: http://jira.jboss.com/jira/browse/JBAS-4689 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JB5-Messaging Reporter: Dimitris Andreadis Assigned To: Clebert Suconic Fix For: JBossAS-5.0.0.Beta3 We are currently at 1.4.0.CR2 -- 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

17 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1018) Possibly fix timeout due to bug in remoting that may allow clients to hang forever.

by Jay Howell (JIRA)

Possibly fix timeout due to bug in remoting that may allow clients to hang forever. ----------------------------------------------------------------------------------- Key: JBMESSAGING-1018 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1018 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Remoting Affects Versions: 1.3.0.GA Reporter: Jay Howell Assigned To: Tim Fox This goes back to JBMESSAGING-171, when we changed the timeout on the bisocket to 0. That would have meant that it would wait forever which is what we want. There is now a bug in remoting that if this is set to 0 and the client is unreachable, then it is possible that it will hang. We may have one case of this now, but it is still unverified. The remoting bug is JBREM-767. This is fixed in the 2.4 beta of remoting, but it may present a problem before we can integrate that version in. We may want to consider changing this to a high number, so it doesn't timeout easily, but so it will timeout. Just want to put it up for concideration. The other route is to get the remoting team to put out another sp version with. They could put it in 2.2.0.SP4_CP02, but that will only go out as part of the Platform 4.2 CR release, so we may want to ask them to put it out as an 2.2.0SP5, so it will go into general population where Messaging has alot of customers. -- 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

17 years, 2 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-357) Update design documentation

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-357?page=all ] Tim Fox updated JBMESSAGING-357: -------------------------------- Summary: Update design documentation (was: Update the Messaging Core documentation) Fix Version/s: 2.0.0 Beta (was: Unscheduled) Description: Make sure design documentation for JBM 2 exists and is up to date. All areas of design should be documentated. Priority: Major (was: Minor) > Update design documentation > --------------------------- > > Key: JBMESSAGING-357 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-357 > Project: JBoss Messaging > Issue Type: Task > Components: Documentation and Training > Reporter: Ovidiu Feodorov > Fix For: 2.0.0 Beta > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Make sure design documentation for JBM 2 exists and is up to date. > All areas of design should be documentated. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-306) Supports recovery flag

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-306?page=all ] Tim Fox closed JBMESSAGING-306. ------------------------------- Resolution: Out of Date > Supports recovery flag > ---------------------- > > Key: JBMESSAGING-306 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-306 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Minor > Fix For: 2.0.0 Beta > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Should have flag "supports XA recovery" on persistencemanager. > If = false then only tx id, not all xid fields are persisted on prepare. This should improve performance when xa recovery is not required. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-158) Tidy up tests

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-158?page=all ] Tim Fox closed JBMESSAGING-158. ------------------------------- Resolution: Out of Date > Tidy up tests > ------------- > > Key: JBMESSAGING-158 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-158 > Project: JBoss Messaging > Issue Type: Task > Components: Tests and Performance > Affects Versions: 1.0.0 alpha PR3 > Reporter: Ovidiu Feodorov > Priority: Minor > Fix For: 2.0.0 Beta > > Original Estimate: 2 days, 4 hours > Remaining Estimate: 2 days, 4 hours > > Tidy up tests: > - Some test classes (and notably MessageConsumerTest) do a lot of Connection/Session/Consumer/Producer creation in setUp(). The original idea was to separate as much boilerplate code as possible, but this leads to hard to understand tests and may lead to unexpected behavior, since the test my get "hidden" intialization it doesn't want. Refactor them and re-write each test to be as independent as possible. > - For tests that send messages in a loop, use a centrally-configured loop counter, which can be easily globally modified. Stress test are more likely to exhibit edge cases and race conditions as the number of message increases, and it should be easy to control that number globally. > Example > public class Global > { > public static final int GENERAL_COUNTER = 100; > .... > } > public class MyTest extends MessagingTestCase > { > // override if it doesn't makes sense locally > protected int NUM_MESSAGES = Global.GENERAL_COUNTER; > ... > } > > - Some tests are not in the right file. > When refactor tests, take extra care not to break their semantics, though. -- 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

17 years, 2 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 November 2007