September 2006 - jboss-dev-forums

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging

by ron_sigal

"ovidiu.feodorov(a)jboss.com" wrote : How does a client get asynchronously messages from the server? I don't remember which Messaging classes are involved, but when a queue or a topic gets a message to transmit, it ends up calling an org.jboss.remoting.Client. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973382#3973382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973382

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging

by timfox

The code in TRUNK doesn't use remoting serialization managers at all any more. I was fed up with the fact that remoting always passed in an ObjectOutput/Input Stream, so I have created new subclasses of ObjectOutput/InputStream called MessagingObjectOutput/InputStream which basically are just a thin wrapper over a straightforward DataOutput/InputStream. This means we can have full control over the bytes we write to the stream without having to worry about all the other serialization header rubbish being written that we don't need. The only times we need to serialize stuff is for non performance critical invocations and for object messages containing a user provided object that we don't know until runtime. In these cases i just create an object output/input stream on the fly and serialize to the dataoutputstream. So the value of serializationType in the uri is completely ignored. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973381#3973381 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973381

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging

by ron_sigal

anonymous wrote : just wanted to clarify that there is no http server on the client side listening for connections from the server side. | | Client side = jms client | | Server side = jms server | | If that's the case, then that's cool :) I'm not sure if the Tomcat connector qualifies as a full-fledged http server, but a Connector's a Connector, wherever it is. Functionally, it's a server running on the jms client side. Normally, the org.jboss.remoting.Client that calls the callback server is built inside of Remoting, but I noticed that Messaging manages its Clients explicitly. So for callbacks, the jms server side is actiing like a client. [Try explaining this in Japan to a room full of people that don't speak English. :-)] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973379#3973379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973379

19 years, 6 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Custom Principal Propagation Related

by scott.stark＠jboss.org

So the issue is how the ejb container getCallerPrincipal is behaving. Let's get the testcase into the testsuite so I can drill down into why the custom principal is not seen. I would suspect its a conflict between run-as behavior and the ClientLoginModule pushed principal. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973377#3973377 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973377

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-549 - Lease set to -1 causes exception

by tom.elrod＠jboss.com

You are right that client should not error because the server says its default lease period is a negative number. I have already checked in a fix for this. However, we need to resolve how all of this works together for leasing. First off, if there is no connection listener registered on the server side, there is no point in doing leasing at all imo (as there will be no one to notify of expired lease). This is why lease period > 0 AND at least one connection listener registred is required to turn on leasing from the server side. Once leasing is turned on and a client has begun to do leasing (meaning there is a leasing sessions in progress on the server side), need to know when they should be cleaned up. Currently there are three cases when this will happen: 1. Client disconnects 2. Client lease is expired (meaning client probably crashed) 3. All connection listeners are removed Notice case 3 is because leasing has been disabled. Then there is the leasing period on the server side. This value is only used as part of the criteria for turning on leasing (having connection listener registered is the other). Once leasing is enabled on the server side and leasing sessions have begun, the lease period on the server side only impacts what the leasing period will be on the client (assuming the client does not override this with their own lease period). This is where the original bug mentioned came in because the client would accept the server's lease period without checking for negative number. So having said all that, does this NOT meet messaging requirements? If not, what should be changed? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973374#3973374 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973374

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging

by ron_sigal

anonymous wrote : | Messaging uses whatever serialization Remoting Connector was configured with, both on client-to-server marshalling and vice-versa. We need to keep this consistent. Take a look at CallbackSErverFactory, for example, to see how this is configured. | I was thinking of the following code from ServerPeer: | // We explicitly associate the datatype "jms" with the java SerializationManager | // This is vital for performance reasons. | SerializationStreamFactory.setManagerClassName( | "jms", "org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager"); | | JMSWireFormat wf = new JMSWireFormat(); | | MarshalFactory.addMarshaller("jms", wf, wf); | I can't see a use of "jms" anywhere in Messaging, so I commented it out. In any case, I updated JMSWireFormat with a constructor which takes an InvokerLocator parameter, from which it attemtps to get a serializationType value. If there is none, it defaults to "jboss". All JMSWireFormat instances in Messaging 1.0 are now created with a call to this new constructor, with the exception of one test case, which should be happy with the defaults (transport = "socket", serializationType = "jboss"). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973373#3973373 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973373

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging

by timfox

I just wanted to clarify that there is no http server on the client side listening for connections from the server side. Client side = jms client Server side = jms server If that's the case, then that's cool :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973372#3973372 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973372

19 years, 6 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Custom Principal Propagation Related

by anil.saldhana＠jboss.com

One security domain. There would be a reauth if the custom principal was ever picked up. It is sitting there on the SA stack. The Simple Principal got propagated. The solution is to provide an option for the user to plug-in a custom principal class into the JBossSecurityMgrRealm. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973371#3973371 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973371

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging

by ovidiu.feodorov＠jboss.com

How does a client gets asynchronously messages from the server? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973370#3973370 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973370

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging (Repost)

by ron_sigal

anonymous wrote : For JMS traffic (e.g. messages) going from server to client, how do you do this? Sorry, Tim, I'm not sure what "this" refers to. But, actually, when you start a callback connector on the client with the http transport, the server side invoker functions like an HTTP server. The message is handled by a Tomcat connector, which calls CoyoteInvoker.service(). Tom could tell you more about it. Before he replaced it with CoyoteInvoker, he wrote HTTPServerInvoker, which is an HTTP/1.1 complient server. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973369#3973369 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973369

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