September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBMESSAGING-431) Socket transports should use configurable port

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-431?page=all ] Tim Fox updated JBMESSAGING-431: -------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.2.0.Alpha1) > Socket transports should use configurable port > ---------------------------------------------- > > Key: JBMESSAGING-431 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-431 > Project: JBoss Messaging > Issue Type: Task > Affects Versions: 1.0.1.CR4 > Reporter: Tim Fox > Assigned To: Ron Sigal > Fix For: 1.2.0.Beta1 > > > Currently, for the socket and ssl transports, callbackservers will be opened on the next available port obtained. > Very occasionally this can fail since some other service uses the port before the callback server can. > Instead, the user should be able to configure a port used by the callbackserver to listen. -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-404) Remove Channel::deliver(Receiver r) method

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-404?page=all ] Tim Fox closed JBMESSAGING-404. ------------------------------- Resolution: Done With the new push style of delivery, this method no longer exists > Remove Channel::deliver(Receiver r) method > ------------------------------------------ > > Key: JBMESSAGING-404 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-404 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.0.Alpha1 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > This method is used to effectively do a synchronous receive() on a channel. > The functionality could be more simply implemented by doing adding a MessageReference receive() method. > This would also help in a clustered environment since we would have one less network RPC. > Most of the complexity here is in updating tests. -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-267) Re-enable distributed tests

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-267?page=all ] Tim Fox closed JBMESSAGING-267. ------------------------------- Assignee: Tim Fox Resolution: Won't Fix These tests are no longer relevant since they test the old clustering code base which is no longer used > Re-enable distributed tests > --------------------------- > > Key: JBMESSAGING-267 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-267 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.0.Alpha1 > > > Distributed destination tests have been disabled until after the 1.0 release since it is time consuming to keep them working when 1.0 will not include distributed destinations and the implementation is likely to change anyway after 1.0. > These tests should be re-enabled and adjusted as necessary for the 1.2 release. > All tests in org.jboss.test.messaging.core.distributed and sub packages have been disabled. -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-199) Fix or mothball remotetopic so it does not require multiple deliveries per message reference

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-199?page=all ] Tim Fox closed JBMESSAGING-199. ------------------------------- Resolution: Won't Fix Remote Topic no longer exists in HEAD with new clustering code > Fix or mothball remotetopic so it does not require multiple deliveries per message reference > -------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-199 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-199 > Project: JBoss Messaging > Issue Type: Task > Components: Messaging Core Distributed Support > Reporter: Tim Fox > Assigned To: Ovidiu Feodorov > Fix For: 1.2.0.Alpha1 > > > Re-implement remote topic to be a router with multiple channels - one per peer. > This means it is not necessary to store receiver id persistently and there is only one delivery per reference per channel. -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-228) Re-enable DistributedTopicTest testDistributedTopic_2() and testDistributedTopic_4()

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-228?page=all ] Tim Fox closed JBMESSAGING-228. ------------------------------- Assignee: Tim Fox (was: Ovidiu Feodorov) Resolution: Won't Fix Old distributed tests are no longer relevant since we no longer use the old clustering code base > Re-enable DistributedTopicTest testDistributedTopic_2() and testDistributedTopic_4() > ------------------------------------------------------------------------------------- > > Key: JBMESSAGING-228 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-228 > Project: JBoss Messaging > Issue Type: Task > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Fix For: 1.2.0.Alpha1 > > > I have overridden org.jboss.test.messaging.core.distributed.topic.base.DistributedTopicTestBase's testDistributedTopic_2() and testDistributedTopic_4(() > because they don't match the current assumption that a Channel has only one receiver, and still we want a clean test run. > Adjust tests accordingly and enable them when this assumption will be better wired into the core and DistributedTopic reviewed. -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-92) Integrate and enable multiplex transport

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-92?page=all ] Tim Fox updated JBMESSAGING-92: ------------------------------- Fix Version/s: (was: 1.2.0.Alpha1) 1.2.0.Beta1 > Integrate and enable multiplex transport > ---------------------------------------- > > Key: JBMESSAGING-92 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-92 > Project: JBoss Messaging > Issue Type: Feature Request > Components: JMS Remoting > Reporter: Ovidiu Feodorov > Assigned To: Ron Sigal > Priority: Critical > Fix For: 1.2.0.Beta1 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Replace "Connector per Consumer" solution with a Remoting UIL2-like transport > The ConsumerInterceptor creates a new Connector instance per each Consumer, and associates maintains a reference to it as transitory metadata, so it can shut it down when the Consumer closes. > The Connector is necessary as a callback server for asynchronous notifications. The MessageCallbackHandler instance is registered to it. Maintaining an instance per Consumer is necessary to avoid port conflicts. > This is a temporary solution until JBoss Remoting gets an UIL2-like transport. > As long as we maintain a server socket per consumer, it won't be possbile to receive asynchronous notifications over firewalls. > until multiplex performance is better it should not be the default tranport but should be available nevertheless -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker configuration and testing

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ] Tim Fox updated JBMESSAGING-207: -------------------------------- Fix Version/s: (was: 1.2.0.Alpha1) 1.2.0.Beta1 > HTTP invoker configuration and testing > -------------------------------------- > > Key: JBMESSAGING-207 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207 > Project: JBoss Messaging > Issue Type: Task > Components: Configuration and Management > Reporter: Ovidiu Feodorov > Assigned To: Ron Sigal > Priority: Critical > Fix For: 1.2.0.Beta1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Provide a HTTP invoker initial configuration and a working example. > Add the example to docs/examples so it can be used as an integration test. -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-766) Don't return unnecessary values from _replicate, avoiding need for marshalling

by Owen Taylor (JIRA)

Don't return unnecessary values from _replicate, avoiding need for marshalling ------------------------------------------------------------------------------ Key: JBCACHE-766 URL: http://jira.jboss.com/jira/browse/JBCACHE-766 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 1.4.0.SP1 Reporter: Owen Taylor Assigned To: Manik Surtani Priority: Minor Fix For: 1.4.0.SP2 This is somewhat related to JBCACHE-752, which suggests setting a marshaller for responses passed over RpcDispatcher as well as for requests, but is a simpler and less general fix. Right now if you set a class loader for a tree cache region, it works for request parameters, but is ignored for returns. If there is an attempt to return a value that needs to be loaded with the class loader, an exception will be thrown. The only return value in normal REPL_SYNC operation is the return value from the key-value put methods, which is the old value, if any. But that return value isn't needed for replication. So, this patch just nulls out the return value from the two affected methods. (We're setting a class loader to deal with the fact that enumerations fields of Hibernate entities are stored directly in the cache, and are serialized/deserialized on replication. There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly hacky manner.) -- 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

19 years, 8 months

3
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-692) UPdate unit tests to use new interfaces

by Manik Surtani (JIRA)

UPdate unit tests to use new interfaces --------------------------------------- Key: JBCACHE-692 URL: http://jira.jboss.com/jira/browse/JBCACHE-692 Project: JBoss Cache Issue Type: Sub-task Reporter: Manik Surtani Assigned To: Manik Surtani -- 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

19 years, 8 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBCACHE-328) Move attributes and getters/setters to interceptors

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-328?page=all ] Manik Surtani closed JBCACHE-328. --------------------------------- Resolution: Won't Fix A different approach is used instead. Cache-wide configuration is encapsulated in a Configuration object, which is injected into each of the interceptors. This way the config can be managed independent of the interceptors. > Move attributes and getters/setters to interceptors > --------------------------------------------------- > > Key: JBCACHE-328 > URL: http://jira.jboss.com/jira/browse/JBCACHE-328 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.0.0 > > > Example: currently IsolationLevel is an attribute of TreeCache. Goal is to make it an attribute of PessimisticLockingInterceptor. > Advantage:no unneeded methods in TreeCache, cluttering up the TreeCache class > #1 Implicit Configuration (conceptual) > -------------------- > <TreeCache> > <Replication> > <config> ... </config> > <mode>ASYNC</mode> > </Replication> > <IsolationLevel> > REPEATABLE-READ > </IsolationLevel> > </TreeCache> > This configures the interceptor chain > #2 Explicit configuration > ------------------------------------ > <TreeCache> > <Interceptor name="PessimisticLockingInterceptor" > class="xxxx" > level="REPEATABLE-READ" /> > <Interceptor>...</Interceptor> > </TreeCache> > The chain is defined explicitly, attributes are defines per interceptor > #3 JMX > If JMx is used, JBossCache is registered with the MBeanServer, and all interceptors are registered under JBossCache, e.g. > type=cache;name=JBossCache1 > type=cache;name=JBossCache1;interceptor_name=PessimisticLockingInterceptor > type=cache;name=JBossCache1;interceptor_name=CacheLoaderInterceptor > type=cache;name=JBossCache1;interceptor_name=ReplicationInterceptor > #4 Programmatic access > Can be done through JMX, but is not nice > cache.getIsolationLevel() --> ((PessimisticLockingInterceptor)cache.getInterceptor("PessimisticLockingInterceptor")).getIsolationLevel() -- 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

19 years, 8 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 2006