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

[Design of JBoss Remoting, Unified Invokers] - Re: Streaming in R3

by trustin

It's a good idea to reuse a particular number of dedicated connection(s) to transfer streams. On the other hand, we will have to split a stream into small chunks to assure minimum QoS of streaming more than one stream with one connection. And then we could fulfill a possible use case that requires no more than one connection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166997#4166997 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166997

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by david.lloyd＠jboss.com

"trustin" wrote : Assuming that David is going to provide an SSH transport in XNIO level, then we could implement a generic transport which depends on XNIO so that it works with any XNIO transports. That was the idea right? Right! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166983#4166983 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166983

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Streaming in R3

by david.lloyd＠jboss.com

In R2 there is a new connection, but it does not support more than one stream per request in any case. In R3 we definitely will use a multichannel facility if it is available (SSH). I plan to use an XNIO ChannelSource to produce channels for R3 streams - the implementation could just create a separate connection but the intent is to use multiplexing whenever it is available. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166982#4166982 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166982

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by galder.zamarreno＠jboss.com

I'm now gonna try to build a jar and integrate it with Portal 2.7.x. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166980#4166980 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166980

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by galder.zamarreno＠jboss.com

http://anonsvn.jboss.org/repos/jbossas/projects/cluster/hibernate-jbc-cac... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166979#4166979 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166979

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by galder.zamarreno＠jboss.com

https://svn.jboss.org/repos/jbossas/projects/cluster/hibernate-jbc-cachep... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166978#4166978 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166978

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - JBoss Managed - CR1

by adrian＠jboss.org

One of the dependencies for MC/Deployers is the JBoss Managed project which is currenlty Scott's project. Scott what is the status of this, do we need a proper CR1 release of this to continue with the finalization of the other MC projects? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166975#4166975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166975

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by david.lloyd＠jboss.com

I'll start replying from the first post. "trustin" wrote : If I remember the latest conversation with David in our IRC channel, our current timeline-less road map looks like the following overally: | | * 3.0 - Stable API and its R2 compatible transports (socket, RMI, servlet, bisocket) | * 3.1 - SSH and other bells and whistles (maybe HTTP or it should go to 3.2) | | Are we all agreed on this overall road map? If so, we could step into more detailed tasks for each milestone. I do agree on this; however it must be said at this point that the R2 compatibility is really not as simple as it might seem, and it might be that we end up doing a 3.0 that simply has the basic transport, 3.1 which adds some R2 types, 3.2 which adds SSH and perhaps more R2 types, etc. I think that it's most important to get a release out this September, and start time-boxing releases, even if it's not immediately usable as a complete Remoting 2 replacement. "trustin" wrote : And... According to the recent discussion ('Hints Welcome'), David also mentioned a simple new R3 implementation for LAN use. I thought we could focus on SSH and use NUL crypto algorythm and no compression. We could also configure each request listener to require different cryptographic strength (perhaps using annotation?). WDYT? A basic protocol implementation is necessary in order to support any SSH-based transport. Since SSH is implemented using multiplexed message-based channels, a protocol implementation is needed which can run over a message-based channel. That's what the basic protocol support is. It is not intended to be directly used in user code due to the lack of authentication, encryption, etc. But it will form the basis for the SSH transport when it is ready. The implementation is a necessary prerequisite to 3.0 - without it, we can't know if the design is even valid. Bear with me for a bit and I'll type up responses to the other posts as well... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166974#4166974 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166974

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: @RemoteBindings and clientBindUrl - JNDI binding questio

by wolfc

There are two problems in the design itself: 1. The transport should be independent of the jndi binding. So depending on which transport I use to connect to jndi (for example https) I should get another client binding. This is an AS issue. 2. The relationship between remote business interfaces and remote bindings is as of yet not properly specified. Let's focus on number 2, because #1 takes more than a simple fix. The goal is to give the bean developer the ability to specify a client bind url per remote business interface. Now in your example you have 2 bindings and 1 interface. In my mind clientBindUrl is an attribute of the remote business interface. But this doesn't allow for multiple bindings per interface. I'm open for any suggestions, but it should not lead to an API change. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166968#4166968 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166968

17 years, 8 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: JBAS-5801 - Locking in 2PC

by adrian＠jboss.org

"jhalliday" wrote : > What we really want to do is make sure that end() blocks | > at tx timeout until the current user operation has completed. | | I'd argue that's exactly what we want to avoid. One use of a tx timeout is to ensure apps don't get stuck due to e.g. slow db queries. If I issue e.g. a SELECT inside a tx and that tx has a timeout, I want it to timeout promptly, not block on the db operation. Likewise for sending or receiving messages. That's part of the reason JBossTS uses a background thread for timeouts. Sure some resource managers have explicit support for configuring timeouts on potentially long running operations, but it's not required. | It doesn't have to block indefinetly, the wait is configurable, |  | <!ELEMENT use-try-lock (#PCDATA)> | but the important thing is that they don't go the wrong way around during normal operation otherwise you end up leaking the work into the "next/no transaction" without error, e.g. Thread 1: does sql executeUpdate(); // Here Thread 1 hits (or more accurately is just about to hit) // the real jdbc connection, e.g. oracle code which we don't control Thread 2: tx timeout Thread 2: end() and rollback() Thread 1: continues with update but now outside the transaction we initially intended anonymous wrote : | I'd say it's up to the resource manager's driver code to decide how to handle the situation. If it's got one thread doing a business logic operation in a tx when another thread is trying to terminate that tx, it can either block internally (I've seen the MS SQL driver do that, queuing the end to go over the same TCP/IP connection when the SELECT eventually returns) or e.g. throw an exception on the business logic thread. | For jdbc the correct thing to do is statement.cancel() although that's not necessarily guaranteed to work depending upon the jdbc driver and only for calls to the driver are that statement executes. anonymous wrote : | That said, one option may be to make this configurable at the JCA level. Allow e.g. -ds.xml files to contain an option for how the JCA should behave - delegate to the driver | We can't do that see the example above. Not because the driver doesn't do its own locking (it probably does) but because it might not understand the required semantics, e.g. session.sendMessage(); // context switched before it actually does it xaresource.rollback(); session,sendMessage() // really executes, but now outside the rolled back transaction anonymous wrote : | as I describe, block as you suggest, | or even explicitly interrupt the business logic and throw an exception as some users seem to expect. The last one of course is risky, it may mess up the underlying driver. That's the mechanism of the previous TM. In fact, what it did besides "interrupting the thread" was effectively destroy the connection (if the I/O was on the same thread and it was in really in I/O) meaning the connection got closed so you couldn't leak into the next/non transaction. Maybe that is an alternate option? i.e. whenever we have a tx timeout, you provide a callback to JCA and then we close the associated connections - disallowing their use which may not be in a well defined state. We could do this on a per connection-factory case depending upon how well we know the underlying thirdparty code handles asynch rollbacks concurrently with normal requests. But my criticism of this is that the connection.close() is still racing with the normal operation outside the intended transaction so it could still complete before we close the connection to "cancel it". Of course, if we closed the connections before the now unnecessary rollback() then this wouldn't be a problem. ;-) BACK ON TOPIC: You didn't answer my question (even though I think I already know the answer :-) which is that we only need to protect the end() invoked by the TM to avoid the race, not the XAResource commit/rollback. Which would mean the transaction interleaving problem of 5801 is easier to solve. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166952#4166952 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166952

17 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-dev-forums July 2008