August 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-812) Specify an API to discover services

by David Lloyd (JIRA)

Specify an API to discover services ----------------------------------- Key: JBREM-812 URL: http://jira.jboss.com/jira/browse/JBREM-812 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Assigned To: David Lloyd Priority: Minor Fix For: 3.0.0.Alpha1 (Otter) The Remoting 3 API presently has a mechanism to discover endpoints and supply information about how to connect to discovered endpoints. A mechanism is also needed to allow a user to find any endpoint that provides a specific service. This mechanism would preferably work in tandem with the existing discovery API. -- 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

15 years, 8 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-963) Work out a mechanism to handle protocol message ordering issues across multiple channels

by David Lloyd (JIRA)

Work out a mechanism to handle protocol message ordering issues across multiple channels ---------------------------------------------------------------------------------------- Key: JBREM-963 URL: http://jira.jboss.com/jira/browse/JBREM-963 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 When dealing with a protocol using multiple channels (HTTP for example, and possibly a future multi-channel JRPP variant), sending two messages on two different channels can cause ordering issues if the second message sent arrives first. For example, sending a context open on channel A, and a request on channel B, may cause the request to be received before the context open message, resulting in the request being rejected with a "no such context" error. Another example is that stream messages must be handled sequentially. There are several possible solutions, including but not limited to: * for any message B that must come after A, always send A and B on the same channel (problem: HTTP channels are transient, so this won't work for HTTP) (problem: this could load up one channel while leaving other channels empty, even if load-balancing is used) * don't send B until after A is acknowledged (problem: acknowledging A might not be possible within the underlying protocol, like if A is sent in an HTTP reply, requiring a separate ACK message, which can lead to performance problems) * if a message comes in seemingly unsolicited (like a request on a nonexistant context) or out of sequence (like in a stream), queue the message for some fixed amount of time to see if the context open message arrives (problem: could be a source of DoS on the server; also this is a duplication of what protocols like TCP already do, which means that all the same problems must be in effect re-solved) Starting a forum thread to discuss the topic. -- 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

15 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1141) Redesign evictions for greater flexibility

by Manik Surtani (JIRA)

Redesign evictions for greater flexibility ------------------------------------------ Key: JBCACHE-1141 URL: http://jira.jboss.com/jira/browse/JBCACHE-1141 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Eviction Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 3.x -- 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

15 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1385) Refactor distribution contents

by Manik Surtani (JIRA)

Refactor distribution contents ------------------------------ Key: JBCACHE-1385 URL: http://jira.jboss.com/jira/browse/JBCACHE-1385 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Scripts and processes Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 3.0.0 We currently ship 3 distros - -bin, -doc and -all. Some things to consider: do we need tests in the -all distro? Do we need the ant script to run tests? Do we need the JBossCacheView demo? Are we better off just referring people to the JBoss Cache GUI Demo [1] ? [1] http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=10... -- 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

15 years, 8 months

1
3
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-131) Cache Loaders (when unshared, and not used with passivation) Should Persist Transient State Upon Startup

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-131?page=com.atlassian.jira.pl... ] Manik Surtani resolved JBCACHE-131. ----------------------------------- Fix Version/s: 3.0.0.BETA1 Resolution: Done > Cache Loaders (when unshared, and not used with passivation) Should Persist Transient State Upon Startup > -------------------------------------------------------------------------------------------------------- > > Key: JBCACHE-131 > URL: https://jira.jboss.org/jira/browse/JBCACHE-131 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Cache loaders > Affects Versions: 1.2.2 > Reporter: Jimmy Wilson > Assignee: Manik Surtani > Fix For: 3.0.0.BETA1, 3.0.0.GA > > Attachments: TreeCache.zip > > > Given the following single, unshared cache loader use case in the TreeCache documentation: > "This is a similar case as the previous one, but here only one node in the cluster interacts with a backend store via its CacheLoader. All other nodes perform in-memory replication. A use case for this is HTTP session replication, where all nodes replicate sessions in-memory, and - in addition - one node saves the sessions to a persistent backend store" > A cache with attached cache loader should persist the transient state of the cache to disk upon startup in order to maintain cache recoverability. > I have modified TreeCache to handle this situation, and I will attach the modified code to this issue. -- 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

15 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1021) JavaSerializationManager should not log exceptions at ERROR level

by Ron Sigal (JIRA)

JavaSerializationManager should not log exceptions at ERROR level ----------------------------------------------------------------- Key: JBREM-1021 URL: https://jira.jboss.org/jira/browse/JBREM-1021 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP9 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP10 If a client disconnects normally, org.jboss.remoting.serialization.impl.java.JavaSerializationManager logs EOFException at ERROR level: ERROR [JavaSerializationManager] java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2498) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1273) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion1_2(JavaSerializationManager.java:180) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:130) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:120) at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59) at org.jboss.remoting.transport.socket.ServerThread.versionedRead(ServerThread.java:663) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:533) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166) The Exception should just be thrown. -- 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

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5660) HASingletonElectionPolicy suitable for mod_cluster

by Brian Stansberry (JIRA)

HASingletonElectionPolicy suitable for mod_cluster -------------------------------------------------- Key: JBAS-5660 URL: http://jira.jboss.com/jira/browse/JBAS-5660 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Paul Ferraro Fix For: JBossAS-5.1.0.CR1 The determination of a singleton master for the mod_cluster intra-cluster comm component has a couple twists: 1) Possibility of one master per mod_cluster domain, rather than one per "cluster" 2) Nodes that are unable to communicate with the httpd side for some reason should not be eligible to servce as master. Need an HASingletonElectionPolicy impl that can handle these requirements. -- 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

15 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-209) Move pojoized version of HASingleton support classes out of AS cluster module

by Brian Stansberry (JIRA)

Move pojoized version of HASingleton support classes out of AS cluster module ----------------------------------------------------------------------------- Key: JBCLUSTER-209 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-209 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Components: HA-Server-API Reporter: Brian Stansberry Assignee: Paul Ferraro Fix For: 1.1.0.CR3 -- 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

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-941) org.jboss.cache.Caches, which allows for users to access a Cache using various collection interfaces

by Elias Ross (JIRA)

org.jboss.cache.Caches, which allows for users to access a Cache using various collection interfaces ---------------------------------------------------------------------------------------------------- Key: JBCACHE-941 URL: http://jira.jboss.com/jira/browse/JBCACHE-941 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Elias Ross Assigned To: Manik Surtani The java.util.Collections utility class supplies useful methods for dealing with legacy interfaces and wrapping collection classes for concurrency, type safety, read-only, etc. In a simiilar vein, I wrote a "Caches" class that returns java.util.Map instances for a Node, which allow data to be modified through the standard Map interface. This I expect to be extremely useful for allowing uses to integrate their existing application with JBoss Cache, and will eliminate some of the confusion of using a new API and they can use the API they know best. Users also often demand an API which is "generic" so that their code is not tied to a particular vendor. There are basically two methods in Caches, one looks like this: Cache cache = DefaultCacheFactory.getInstance().createCache(); Map m = Caches.asMap(cache); m.put("foo", "bar"); The API and examples explain themselves. "Caches" could also include other useful methods for printing or reporting. Note that this functionality could be considered duplicated from PojoCache...) -- 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

15 years, 8 months

3
13
0 / 0

[JBoss JIRA] Created: (JBAS-5836) Upgrade jbossws to 3.0.3

by Dimitris Andreadis (JIRA)

Upgrade jbossws to 3.0.3 ------------------------ Key: JBAS-5836 URL: https://jira.jboss.org/jira/browse/JBAS-5836 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Web Services Reporter: Dimitris Andreadis Assignee: Thomas Diesler Fix For: JBossAS-5.0.0.CR2 Track the upgrade of jbossws -- 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

15 years, 8 months

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2008