[Design of JBoss jBPM] - Re: MessageService and JMS
by mteira
Please, could someone make some comment about my thoughts about the JMS service implementation?
JmsMessageServiceImpl requires a JMS queue, used to send messages containing serialized jobs. Looking at the code, it seems that there's no developed component to listen into that queue and consume the jobs. Is this a missing part of the system? (An MDB to consume those jobs to replace the Servlet used now to execute the jobs).
Also, what's the conceptual difference between Commands and Jobs. I mean, couldn't the tasks performed by the Jobs be implemented as Commands to be consumed by the CommandListenerBean, and be executed in a CommandService Session?
I want to apologize for asking this more than once, but I've being requested to present a viability report for jBPM, and I need to understand how the JMS based Service works, and what is missing to be implemented.
Best regards.
--
Manuel.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979592#3979592
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979592
19 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Client Asynchronous Calls
by timfox
"ovidiu.feodorov(a)jboss.com" wrote :
|
| As far as I remember, the current code relies on the fact that it receives an acknowledgment (in the form of an exception NOT being thrown) for each server->client delivery.
|
|
Sure, the current code uses RPC, we don't have a choice with the version of remoting we are using, that's the only reason it's that way.
But it is unnecessary.
Actually we can radically simplify the server consumer endpoint message dispatch if we go async - no need for the deliverer or any of that stuff any more - less context switches etc
anonymous wrote :
| Well, in this case AMQP has a problem if it doesn't also provide for synchronous client-to-server delivery. Need to hit the books, to make sure this is (or not) the case.
|
I think AMQP supports both sync AND async. I need to hit the books too :)
anonymous wrote :
| Right. So ConnectionEnpoint.sendTransaction() IS a RPC.
|
It is. Did I say otherwise?
anonymous wrote :
| We're clear. We need both. And this needs to be reflected in the Remoting API. I'll soon add the document with the proposed changes.
|
Cool
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979589#3979589
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979589
19 years, 5 months
[Design of Security on JBoss] - Re: Negotiate with Kerberos
by ramesh4u
Please help me........
I have a windows network (samba domain controller which intern uses the flat file system for datastore), I wanted my j2ee web application to authenticate using NegotiateKerberos. so i followed http://wiki.jboss.org/wiki/Wiki.jsp?page=NegotiateKerberos link to setup your test application but it is not working. when i request for the index.html, i get [org.jboss.web.tomcat.security.HttpServletRequestResponseValve] Realm returned: null in the jboss server.log....
Following configurations i have done
Windows network domain name is LK
Samba domain controler ip 192.168.1.7
/conf/login-config.xml
<!-- SPNEGO test -->
<application-policy name = "SPNEGO">
<login-module code="org.jboss.security.auth.NegotiateLoginModule"
flag = "required">
<module-option name="loadBalance">false</module-option>
<module-option name="domainController">192.168.1.7</module-option>
<module-option name="defaultDomain">LK</module-option>
</login-module>
</application-policy>
/WEB-INF/web.xml
<login-config>
<auth-method>Negotiate</auth-method>
<realm-name>SPNEGO</realm-name>
</login-config>
<security-role>
<role-name>LK</role-name>
</security-role>
WEB-INF/jboss-web.xml
<jboss-web>
<security-domain>java:/jaas/SPNEGO</security-domain>
</jboss-web>
Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979584#3979584
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979584
19 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Server-side Thread-per-connection Model
by ovidiu.feodorov＠jboss.com
Tom wrote :
| Remoting currently views things in terms of the Object world, meaning at the highest API level, it expects to be dealing with objects. Then as dive deeper in the guts of remoting were have transport and marshalling, the same theme still exists (although not as tightly constrained). Think what Scott is talking about is having the transport layer so that at lowest level is only dealing with raw data, then passes that data to a higher level, where would be converted into whatever format (an Object for example), then pushed up.
|
How about exposing access to raw data from the top-most level, specifically to allow speed optimizations like sending fast, high-throughput (that means no serialization or marshalling) acknowledgments, something that we need in Messaging, for example?
Tim wrote :
| For messaging we would probably just use the very lowest level and forget about the rest.
|
No. We also need invocations (high level). See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=92954
Tim wrote :
| However, is it realistic to get it implemented this way in our timescales?
|
I don't think it's so complicated. The implementation doesn't need to be perfect from the first try. We only need to get the API right.
Tim wrote :
| If we want to compete in the "enterprise" market (large telcos / banks) I suggest we need to support 1000s of connections, in which case I very much doubt a blocking approach is going to work well.
| If we're happy living in the small office, hobby user market then sticking with blocking might be an acceptable route IMHO.
|
How about we have both? And a huge red double-pole-service-disconnect kind of breaker saying on one side "Enterprise" and on the other "Hobby User"? :)
Seriously now, I don't disagree at all that high end goes with NIO. The doubts I have are related to how NIO performs in the case when you have just two clients that keep sending messages for a month on a "keep-alive" connection. But I think we already agreed on the fact that we need to bench.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979564#3979564
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979564
19 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Client Asynchronous Calls
by ovidiu.feodorov＠jboss.com
Tim wrote :
| For pushing from server->client, for the reasons already stated (latency problems) an RPC model will ruin performance.
|
As far as I remember, the current code relies on the fact that it receives an acknowledgment (in the form of an exception NOT being thrown) for each server->client delivery.
Tim wrote :
| For sending from client to server, yes you are correct in stating this must be RPC, for JMS at least, although AMQP is less strict on this and allows asynchronous send I believe.
|
Well, in this case AMQP has a problem if it doesn't also provide for synchronous client-to-server delivery. Need to hit the books, to make sure this is (or not) the case.
Tim wrote :
| So, for JMS, to maximise sending throughput for a high latency network would be done on the application level by sending messages in transactions with multiple messages per transaction. This allows many messages to be sent in one RPC.
|
Right. So ConnectionEnpoint.sendTransaction() IS a RPC.
Tim wrote :
| Let's be clear on this. I am not advocating an all or nothing asynchronous approach. Of course some operations need to be synchronous.
|
We're clear. We need both. And this needs to be reflected in the Remoting API. I'll soon add the document with the proposed changes.
Tim wrote :
| However most of the operations (with the exception of send) on the primary execution paths can probably be done asynchronously.
| These are the ones that need to be fast, they include:
| Sending messages from server=>client
| Flow control messages (currently just more()) but we will need to extend this probably.
| Acknowledgements (I am pretty sure but not 100% about this one - it needs more thought)
|
This is exactly what I was saying. See above (or below):
Ovidiu wrote :
| This leaves us SessionEndpoint.acknowledgeBatch(), SessionEnpoint.acknoweldge() and ConsumerEndpoint.more() that can arguably improve the throughput if they're made asynchronous. Also, sending the message to the client for delivery is a good candidate for asynchronicity.
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979562#3979562
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979562
19 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Multiplexed (Bidirectional) Transport
by ovidiu.feodorov＠jboss.com
Tom wrote :
| Although a callback server is needed on the client side, this does not necessarily mean a server socket is needed.
|
Why would be a callback server exposed in API and required to be explicitely created on the client side?
You only need to create a client for a specific server and then declare that you want to receive push callbacks from that server. All you need from an API point of view is to call
client.setListener(CallbackListener)
The server knows exactly what client added the callback listener, so if the connection happens to be over a bidirectional transport, the server knows how to get back to it. No need to expose the callback server in API in this case, it only adds extra complexity.
For a unidirectional socket transport, yes, fine, but we want to improve the API, not stick to something that doesn't exactly fit our needs.
Ron wrote :
| There is another solution to the firewall problem.
| Tom implemented a polling callback mechanism [I think it was requested by the Messaging group] which simulates the use of a callback server on the client side. I've used it on the Branch_HTTP_Experiment Messaging branch to avoid client side server sockets with the HTTP transport, but it would work with the socket transport as well.
|
... and it will be horribly slow.
Why complicate things? Bidirectional TCP socket connection, it's all we need. And polling for HTTP, but there is no way around that there.
Ron wrote :
| 2. I'm not sure what a bidirectional channel would look like in Remoting, but there's a sense in which Remoting connections are close to a bidirectional channel. From client to server, there's the option of an invocation which is asynchronous at the application level, i.e., it returns immediately, and with the NIO transport it will be asynchronous at the transport level. From server to client, callbacks are not too conceptually different from asynchronous invocations. A payload is passed to Remoting and on the other side it lands on an application level handler. It may not be as elegant as a bidirectional channel,
|
>From an API perspective, client to server invocations (synchronous and asynchronous) and server to client callback (synchronous and asynchronous) is all we need. Remoting is very close to that, and I will soon publish a wiki document with suggested API amendments. But this is not the problem. The problem is that we don't need to mess around with virtual sockets to get bi-directionality. A TCP connection is inherently bi-directional. You write stuff at this end and it comes out at the other end. You write stuff at the other end and it comes out at this end. Remoting should take advantage of that in the simplest way possible. Write a different transport for that, call it "bidirectional" or "nebuchadnezzar", doesn't matter, and Messaging will use it.
Tim wrote :
| Ron wrote :
| | 2. I'm not sure what a bidirectional channel would look like in Remoting,
| |
| I was thinking something vaguely similar to the Channel interface in Java NIO, except it would need to support both synchronous and asynchronous invocations.
|
I'll very soon publish some suggestions to amend the Remoting API. It only adds things to it, and keeps everything else pretty much as it is, so current application won't break. It'll be a wiki document, I'll link it here.
Tim wrote :
| Also, what does the current wire format of the multiplex transport look like? Is it based on frames? Or some other way of doing it?
|
I don't think we should even touch the current multiplex transport. It doesn't make sense to do that for AMQP. In AMQP we don't control the client, the concept of invocation is irrelevant, we just get a bunch of bytes on the wire, so we need to add a protocol handler on the server that "generates" invocations out of the protocol stream.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979558#3979558
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979558
19 years, 5 months