[Deployers on JBoss (Deployers/JBoss)] - Re: Deployment dependencies via WebMetaData and ServiceMetaD
by bstansberry@jboss.com
I walked through this in a debugger yesterday and didn't see any logic to "fail" from a missing dependency. ServiceController's install/create/start methods tell the KernelController to bring the context to CONFIGUGRED/CREATE/START and just log a debug if something prevents that.
Basically it looks the deployment remains registered, waiting for the missing dependency to be resolved, which could happen at any future time. Only indication of a problem is if someone like HDScanner calls MainDeployer.checkComplete() and logs the DeploymentException.
Leaving the deployment in place waiting for the dependency to be resolved seems fine actually, as long as we make sure any code we write that initiates deployments also calls checkComplete() and does something useful with the output. [1] IIRC, that's how AS 4 works as well.
The thing that definitely did seem bad was the jmx-console mbean for the WebModule was pretty useless. No attribute to tell you what ControllerState it was in, just the lifecycle ops.
[1] A bunch of our unit tests in o.j.test.deployers try to deploy things and don't call checkComplete(). I suspect this may leave them vulnerable to thinking a deployment has completed when it really hasn't. For JBAS-4763 I created a test based on the others and got bit by that.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123761#4123761
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123761
16 years, 11 months
[Design of Messaging on JBoss (Messaging/JBoss)] - New transport: Determining oneway messages
by timfox
Several messages, e.g. acknowledge or cancel etc, can be sent wither oneWay or blocking depending on the particular use case.
Currently when such is processed on the server, there is currently no generic way to know whether a response is required to be sent.
SendMessage currently does this by checking whether the message is durable.
I think we need some generic way of a packet knowing whether a response is required (e.g. a oneway flag in AbstractPacket) rather than having to rely on application semantics to determine whether a response should be sent.
Currently I am just always sending a response even for one way calls (since I don't know they are oneway), this gives me lots of:
|
| Thread-168 10:22:12,758 ERROR [PacketDispatcher] Packet is not handled, it has no targetID: PACKET[type=NULL, version=0, correlationID=-1, targetID=NO_ID_SET, callbackID=NO_ID_SET]
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123729#4123729
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123729
16 years, 11 months