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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

by jmesnil

"timfox" wrote : | Yes, persistent messages are sent blocking request / response, non persistent messages can be sent fire and forget (not response required at all). | | But there is a third mode: non blocking request /response. | | This is where you send the request, but you don't block. The server receives the request and processes it. The server then sends back a response. The response gets handled on the client side by a different thread to that which sent the request. These semantics aren't supported by JMS. But would be very useful for our generic API by giving very high throughput for persistent messaging sending since it wouldn't be limited by the network RTT as it is in the blocking case. This 3rd case is meant to be covered by sendOneWay(AbstractPacket packet, PacketHandler callback). For now, the response is handled by the same thread which sent the request but I plan to use an ExecutorService to have other threads take care of handling the packet View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104447#4104447 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104447

18 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

by timfox

"jmesnil" wrote : | | I'm not sure to follow you: we need to support blocking req/resp for some of our operations (e.g session creation), don't we? | Yes, persistent messages are sent blocking request / response, non persistent messages can be sent fire and forget (not response required at all). But there is a third mode: non blocking request /response. This is where you send the request, but you don't block. The server receives the request and processes it. The server then sends back a response. The response gets handled on the client side by a different thread to that which sent the request. These semantics aren't supported by JMS. But would be very useful for our generic API by giving very high throughput for persistent messaging sending since it wouldn't be limited by the network RTT as it is in the blocking case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104437#4104437 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104437

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 AppClient - tests now pass but there are issues

by wolfc

"adrian(a)jboss.org" wrote : Isn't it just a case of proxying the persistent context requests over remoting | and making sure the request handling on the server side runs | in any UserTransaction context created on the client? | | I think we can do that in the appserver without hibernate having to implement it. Nope, there are all sort of issues that pop up with detached and attached entities. My approach was to make the DataSource remote and use 'local' JPA. But that would require a translation of the remote persistence descriptor somewhere. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104433#4104433 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104433

18 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

by jmesnil

"timfox" wrote : | Can targetID and callback id be longs (or ints?) too? | | I'm thinking that Java guids are pretty long, and we want to keep the packets as small as possible - maybe I'm being over conservative though... | I went for convenience in the API and using Strings for the IDs makes it possible to use Java 5 UUID and get rid of all the complexity we got from generating our own IDs (as planned by http://jira.jboss.org/jira/browse/JBMESSAGING-1040). However you're right that it increases the size of the packet by doing so. Depending on the payload of the packet, it may be negligible... or not. For now, I'd keep the String ID and flag it as an area of optimization. anonymous wrote : | Do connect and disconnect really belong on the RemotDispatcher? | Not really :) The RemoteDispatcher corresponds to both JBM 1.4.x Dispatcher (register/unregister) & JBoss Remoting Client (connect/disconnect/send). Given the simplicity of the API, I keep the functions together in a single type but conceptually they belong to 2 different types. As complexity grows, I'll likely refactor it. anonymous wrote : | Three different ways to exchange packets - the second way (e.g. send non persistent message) - in fact, non persistent messages can be fire and forget - non blocking request / response is not supported using the JMS API but is very useful for doing stuff over and above JMS which we can expose through the generic interface. | I'm not sure to follow you: we need to support blocking req/resp for some of our operations (e.g session creation), don't we? anonymous wrote : | responses via HTTP - is this done by keeping the http connection open and sending responses that way? I can't see it work otherwise without polling. | That's the way it seems to work: the connection corresponds to a Keep-Alive HTTP connection (kinda...) I'm still not 100% clear on HTTP support: I'm able to use curl and firefox to send and receive on HTTP & HTTPS but ab is not working for now... anonymous wrote : | http post: i can see that encoding requests as http params is not always going to work - especially if we have to tunnel through another web server who will limit http params to a max length - can we extend the http codec to do this differently? The decoding of HTTP post is done by AsyncWeb (a minimal HTTP server implementation on top which should land into MINA trunk) . Trustin plan to get it integrated for MINA 2.0 (The POST parsing issue is tracked by http://jira.safehaus.org/browse/ASYNCWEB-24[/url]) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104425#4104425 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104425

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Great error message!

by wolfc

Well, you're not showing the entire trace, but my guess is it won't get any better. :-) Raise a Jira. I hate these kind of errors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104420#4104420 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104420

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JNDI Binding and ejbcontext test

by wolfc

Does MC call stop if start fails? I thought it did. Or in general: should start, on error, set the system in the previous state? I'm in favor, but that contradicts MC. Enlighten me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104419#4104419 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104419

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: New Build Artifact - EJB3 External API

by ALRubinger

I have: * Centralized @CacheConfig * Restructured to @Cache("RegisteredCacheType") * Restructured to @Pool("RegisteredPoolType") * Moved @Clustered to "cluster" project * Moved the External API from JBoss AS EJB3 Core to projects/ejb3 and included in classpath as thirdparty library. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104381#4104381 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104381

18 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Leaking annotation API

by ALRubinger

"bstansberry(a)jboss.com" wrote : Seems the @Clustered annotation really is EJB-specific. With EJB3 you can still configure EJB homes, and that implies you should be able to configure a home load balance policy: http://jira.jboss.com/jira/browse/EJBTHREE-1110 . Adding an attribute for that makes this an ejb annotation. Can still go in the ha-client.jar though. FYI, today I'd moved it to HA and out of the EJB3 External API. cluster/org.jboss.annotation.ha.Clustered Maybe instead of adding an EJB-specific attribute to @Clustered, we make another annotation alltogether to configure the home load balance policy, placing that in EJB3? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104378#4104378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104378

18 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Leaking annotation API

by bstansberry＠jboss.com

Seems the @Clustered annotation really is EJB-specific. With EJB3 you can still configure EJB homes, and that implies you should be able to configure a home load balance policy: http://jira.jboss.com/jira/browse/EJBTHREE-1110 . Adding an attribute for that makes this an ejb annotation. Can still go in the ha-client.jar though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104373#4104373 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104373

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Setting load-balance-policy

by bstansberry＠jboss.com

Seems the clustered proxy factories didn't support binding home proxies at all: http://jira.jboss.com/jira/browse/EJBTHREE-1109 Allowing configuration of home load balance policy: http://jira.jboss.com/jira/browse/EJBTHREE-1110[/url] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104370#4104370 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104370

18 years, 4 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 November 2007