July 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Portal] - Re: Java 5 migration strategy

by thomas.heute＠jboss.com

Right now we import the backported library so that it works on JBoss AS 4.2 (which doesn't support a JDK 1.4) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061990#4061990 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061990

18 years, 9 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Serialization with NIO

by david.lloyd＠jboss.com

The jserial project (http://jserial.sourceforge.net/index.html) almost had the right idea - serializing to a buffer - but from what I can see, they do not account for the problem where a serialized object doesn't fit into the buffer. In this case, it's no better than Java serialization using a custom OutputStream that writes to a ByteBuffer... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061986#4061986 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061986

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Java 5 migration strategy

by bdaw

One particular thing is java.concurrent package as we were using 'edu.emory.mathcs.backport' stuff. Do we want/need to migrate it to java 5 implementation? The API should be the same so changing imports should be enough no? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061984#4061984 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061984

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Where do we want to put

by mark.little＠jboss.com

I created a JIRA for it, so we can at least track it later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061958#4061958 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061958

18 years, 9 months

1
0
0 / 0

[Design of JBoss Serialization] - Serialization with NIO

by david.lloyd＠jboss.com

Looking at adapting JBoss Remoting to NIO, and I've encountered a problem with serialization. Ideally, using NIO, a small pool of threads can handle a large number of connections. The amount of time that a server thread spends processing a request should be minimized; ideally only invocations should be using a thread for any substantial amount of time. Because the serialization API uses the old stream I/O methodology, it requires that blocking I/O be used to process the serialization/deserialization of objects. This causes a scalability issue (thread-per-connection) that cannot be completely solved with NIO. Two ways in which the problem may partially be solved: 1. Use (simulate) blocking I/O only during (de)serialization. There are several ways this can be done with similar results. 2. On the sending side, serialize objects to a local buffer first; use NIO to send the buffer (perhaps with a size header). On the receiving side, read the network data into a buffer, and once the buffer is filled, deserialize the buffer data. The advantage to 1 is that it streams the buffer data; however, a server thread will be monopolized during the entire transmission of a serialized object. If the sending side is slow or intermittent, or if the data to transmit is large, a thread pool can be consumed indefinitely by a small number of clients. Blocking timeouts can mitigate (but not solve) this problem. The second approach does not suffer from this problem. The serialization process can run from start to finish without blocking; the buffers can then be sent in a non-blocking fashion. The receiving side does not begin deserialization until the whole buffer is in memory, so it will not block either. However, memory overhead might become substantial for larger objects. An ideal solution to this problem (from my perspective) would be to provide an NIO-compatible API. For serialization, the API would have the user push in an object, and then push in buffers repeatedly until the object is fully serialized: | public interface Serializer { | void setObject(Object source); | /** @return {@code true} when the object is serialized fully */ | boolean fillBuffer(ByteBuffer target); | } | For deserialization, the API would accept buffers, and allow the user to pull objects (accounting for the possibility of more than one object coming from a single buffer): | public interface Deserializer { | boolean hasNext(); | Object next(); | void setBuffer(ByteBuffer input); | } | This API would be used like this: | .... we just got a buffer .... | deserializer.setBuffer(input); | while (deserializer.hasNext()) { | Object nextObj = deserializer.next(); | .... do something with nextObj .... | } | This API would allow for maximum scalability by lifting the blocking I/O requirement. A stream API can be implemented on top of this API; however the reverse is not true. Is this type of API a possibility for JBoss Serialization? For extra credit, would it be possible to make an implementation that is wire-compatible with Java Serialization? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061949#4061949 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061949

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Partitioning in JBoss Cache - JBCACHE-60

by manik.surtani＠jboss.com

"bstansberry(a)jboss.com" wrote : (Note there's no need to have a "PartitionGroup per session". You just have enough regions/PartitionGroups to adequately divide the failover load and then organize how the sessions are cached accordingly.) Yes, you could use a fixed number of partition groups and spread the number of sessions in each PG evenly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061945#4061945 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061945

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Where do we want to put

by tfennelly

"Kevin.Conner(a)jboss.com" wrote : "tfennelly" wrote : soapui-client | I thought this was a "JBoss MBean" service, not an ESB one. | Right, but that doesn't mean it can't have a dependency on common utilities. "Kevin.Conner(a)jboss.com" wrote : In any case, doesn't it already include jbossesb-rosetta.jar? | You're actually right there Kev - I forgot that. You know why this is? Because it depends on some utility code (OGNLUtils and YADOMUtil) that's bundled in rosetta (the core of the ESB). It actually has no dependencies on the real core ESB code. Anyway guys, as I said... lets make it (leave it) dependent on rosetta. I personally think that sucks but ... :-) Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061940#4061940 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061940

18 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Using JBossSerialization with HttpSession Replication (J

by hmesha

for any attribute to be replicated, it must implement serializable. Regardless of the session replication policy in effect. JBossSerialization implmentation is meant to be used instead of Java Serialization for replication and not meant to deal with non-serializable attributes. It's possible to use JBoss Serialization to serialize non-serializable before replicating them but that require further developement and it was beyond the scope of JBAS-2921. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061937#4061937 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061937

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Where do we want to put

by Kevin.Conner＠jboss.com

"tfennelly" wrote : soapui-client I thought this was a "JBoss MBean" service, not an ESB one. In any case, doesn't it already include jbossesb-rosetta.jar? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061935#4061935 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061935

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Where do we want to put

by tfennelly

"mark.little(a)jboss.com" wrote : "tfennelly" wrote : At the moment, this seems to be getting dumped in the "rosetta" codebase, meaning that if you have a service that needs a particular utility, it ends up being dependent on the core of the ESB. | | I think this statement is the one that really confused me. What services are we developing that don't have a dependency on the core of the ESB ;-)?! soapui-client I need to add some Commons HttpClient support code that both the "soapui-client" and "soap" services will depend on. Don't worry about it. I'll just add it to rosetta and make the soapui-client depend on it :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061929#4061929 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061929

18 years, 9 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-dev-forums July 2007