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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Thread usage in AIO layer

by timfox

Isn't there a possibility that it moves to the next file, and it's still waiting for completions to come in on the last file, then it fills the next file too, then tries to move to the next one, but there is no cached file, because completions haven't all come in for the first file? What happens in that case? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173335#4173335 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173335

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Thread usage in AIO layer

by clebert.suconic＠jboss.com

"timfox" wrote : Can't completions come in for a previous file once we've already moved to the next file? Yes... When the journal needs a new file it will: - Immediately return the next file (cached). Writes will start on the next file without any waits. In an executor: A- It will wait the pending writes to finish before it can close the file, and then close the file (This won't affect any of the transactions. It's just that I need to wait executions to finish before I can close the file or I would loose data) B- It will place another file back to the nextOpenFile cache. I have tested this and I didn't see any latency because of that. BTW: (A) is being tested under one of the integration tests, as this used to cause a crash on the native layer before Alpha. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173332#4173332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173332

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Thread usage in AIO layer

by timfox

"clebert.suconic(a)jboss.com" wrote : That's why we don't keep all the files opened. That's one thing I changed on the journal. We only keep the currentFile opened. | | If we have lots of files on the journal, you will awats only have two threads. | \ Can't completions come in for a previous file once we've already moved to the next file? Or do we block waiting for all completions when moving to the next file? If the latter, doesn't this introduce latency? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173328#4173328 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173328

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Thread usage in AIO layer

by clebert.suconic＠jboss.com

We keep the currentFile, and a cache for a nextOpenFile. So, you aways have one file opened, and a cached one waiting when you need to open a new file. (So there is no wait on openFile inside the Journal). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173326#4173326 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173326

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Thread usage in AIO layer

by clebert.suconic＠jboss.com

That's why we don't keep all the files opened. That's one thing I changed on the journal. We only keep the currentFile opened. If we have lots of files on the journal, you will awats only have two threads. \ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173323#4173323 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173323

15 years, 7 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: XTS Participant APIs for use by Web Service-specific cod

by mark.little＠jboss.com

"adinn" wrote : Ok, I raised a JIRA (JBTM-393) to cover any possible action on this but it really needs discussion first. Here is what I wrote in the JIRA: | | anonymous wrote : | | The BAWithXXXCompletionParticipant interfaces which define the API implemented by Web service-specific participant implementations (and also the participant stubs on the coordinator side) include methods with the following signatures: | | | | | | | public String status() throws SystemException; | | | public String unknown() throws SystemException; | | | public String error() throws SystemException; | | | | | | | These appear to relate (vaguely) to the BA protocol message pair GetStatus (request) and Status (response) | | | Almost. These operations existed in the API before there was anything equivalent in the WS-TX specification, let alone the WS-TX standard. So before I go on, a quick history lesson: XTS began life as an offshoot of HP-WST, which was based on OASIS BTP. When that fizzled out we began to target WS-T 1.0 (the precursor to WS-TX) but also WS-CAF (and in this case WS-LRA). Some of the operations that appear in the API we've got now reflect more on what was in WS-CAF that WS-TX because the interfaces were richer (and still are in some ways). Anyway, I digress slightly. Eventually WS-TX 1.0 moved to adopt status operations. But even then they are not exactly the same. You also need to know that recovery was pretty poorly defined in the earlier drafts of the WS-T specification (it hasn't really improved that much, to be honest). These are (or were) meant more for recovery purposes. I'm assuming you've read the comments in the code, as they do explain them somewhat. anonymous wrote : | anonymous wrote : | | which can be initiated from either the coordinator or the participant. If so then they appear to be inappropriate as part of the Web service-specific API. The application does not and, indeed, should not need to know about the state model employed by the protocol implementation. | | | They're not there for the application, they are there for the participant implementation. Think RecoveryCoordinator in OTS, with it's replay_completion. anonymous wrote : | anonymous wrote : | | status() probably ought to be dropped and maybe also the other two. However, it may be that error and unknown are intended to be called during recovery processing or,perhaps, even normal processing (e.g. if the participant receives an InvalidState fault or a Failed message). So, this needs to be clarified first. | | | status is meant to be called by the coordinator on the participant. Like "how are you doing, please to meet you, now can you please tell me where you are in the protocol." So this is part of top-down recovery. unknown and error are the reciprocal operations for when the participant calls up (bottom-up recovery) to the coordinator "nice to meet you, can you please tell me what's happening with the transaction I was within?" anonymous wrote : | anonymous wrote : | | The message handlers for the i) GetStatus and ii) Status messages are currently implemented, respectively, i) to dispatch a Status message with the current (service or coordinator-side) participant engine state and ii) to do nothing. The current implementation does not ever dispatch a GetStatus message -- it is not necessary to do so for the purpose of implementing recovery on either the coordinator or the participant side. Since the BA spec provides no details as to when or how these messages are to be used the current implementation is, perhaps, appropriate, This needs to be clarified and, if necessary, the code modified to verify its use. | | | I'd like to go through the recovery details you've got in your head at the moment and see how you're expecting to replace these current calls. Is there something I can read? anonymous wrote : | So, I will start the discussion with a question. Anyone know the intention behind defining the Participant API this way? | | I can't see why status() is specified to return a String -- what String generated by the Web service would be meaningful here? I can see how it might conceivably be useful for the participant engine to tell the participant what its status is (using, say, a String rendering of one of the predefined State values) but not the other way round. | Hopefully that's answered now? It was a QName originally. anonymous wrote : | The other methods might be helpful during recovery or when processing failure notifications but, once again, I am not exactly sure what the envisaged scenario is that is not covered by the actions detailed in the transition tables. This is maybe where the GetStatus/Status messages come into the equation. | Maybe, but the spec. only covers the basics. For example, where in WS-AT does it talk about top-down or bottom-up recovery ;-) ? anonymous wrote : | It looks as if the spec was designed so that the coordinator would check up on its participants (or rather the engines which wrap them) during crash recovery by sending GetStatus and seeing what state they thought they were in. Ditto the participants (the engines) would use GetStatus to check what the coordinattor thought their status was during crash recovery. | | Is this actually necessary? Do the state transitions not ensure that each participant knows exactly what to do in the event that it is recovered and reactivated? | And what about time outs, autonomous choices etc. BA does not avoid heuristic decisions. No matter what we might have tried to hide in WS-AT, it doesn't either. anonymous wrote : | Is the idea of unknown() that it provides a way for a reactivated participant to clear up its compensation data? If so then why is this not covered by the normal state transitions? | No. The idea (back then) was that the participant does an upcall to a transaction manager asking for the status of transaction XYZ. That transaction isn't available any more so it must have rolled back. Just like OTS, the participant expects a status (unknown in this case, which can be interpreted as rolled back), even if the act of enquiring also kicks of recovery top-down. anonymous wrote : | Is error() supposed to be called when a failure occurs? This does not seem very helpful because the participant will normally only send FAIL to the coordinator and get a FAILED response because the participant has thrown an exception. | No. Similar to above, it's the coordinator-side (or something acting on its behalf, like the SOAP stack at the coordinator or participant) that drives these messages. In this case the participant has enquired as to the status of the transaction and there has been an error, e.g., a comms failure. Because all of the interactions are modeled as one-way's we need some way of communicating that back to the participant. BTW, it may be useful to check out the WS-CAF docs because at least in those we also included interaction diagrams :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173320#4173320 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173320

15 years, 7 months

1
0
0 / 0

[Design of JBoss Transaction Services] - XTS Participant APIs for use by Web Service-specific code

by adinn

Ok, I raised a JIRA (JBTM-393) to cover any possible action on this but it really needs discussion first. Here is what I wrote in the JIRA: anonymous wrote : | The BAWithXXXCompletionParticipant interfaces which define the API implemented by Web service-specific participant implementations (and also the participant stubs on the coordinator side) include methods with the following signatures: | | | | public String status() throws SystemException; | | public String unknown() throws SystemException; | | public String error() throws SystemException; | | | | These appear to relate (vaguely) to the BA protocol message pair GetStatus (request) and Status (response) which can be initiated from either the coordinator or the participant. If so then they appear to be inappropriate as part of the Web service-specific API. The application does not and, indeed, should not need to know about the state model employed by the protocol implementation. status() probably ought to be dropped and maybe also the other two. However, it may be that error and unknown are intended to be called during recovery processing or,perhaps, even normal processing (e.g. if the participant receives an InvalidState fault or a Failed message). So, this needs to be clarified first. | | The message handlers for the i) GetStatus and ii) Status messages are currently implemented, respectively, i) to dispatch a Status message with the current (service or coordinator-side) participant engine state and ii) to do nothing. The current implementation does not ever dispatch a GetStatus message -- it is not necessary to do so for the purpose of implementing recovery on either the coordinator or the participant side. Since the BA spec provides no details as to when or how these messages are to be used the current implementation is, perhaps, appropriate, This needs to be clarified and, if necessary, the code modified to verify its use. | So, I will start the discussion with a question. Anyone know the intention behind defining the Participant API this way? I can't see why status() is specified to return a String -- what String generated by the Web service would be meaningful here? I can see how it might conceivably be useful for the participant engine to tell the participant what its status is (using, say, a String rendering of one of the predefined State values) but not the other way round. The other methods might be helpful during recovery or when processing failure notifications but, once again, I am not exactly sure what the envisaged scenario is that is not covered by the actions detailed in the transition tables. This is maybe where the GetStatus/Status messages come into the equation. It looks as if the spec was designed so that the coordinator would check up on its participants (or rather the engines which wrap them) during crash recovery by sending GetStatus and seeing what state they thought they were in. Ditto the participants (the engines) would use GetStatus to check what the coordinattor thought their status was during crash recovery. Is this actually necessary? Do the state transitions not ensure that each participant knows exactly what to do in the event that it is recovered and reactivated? Is the idea of unknown() that it provides a way for a reactivated participant to clear up its compensation data? If so then why is this not covered by the normal state transitions? Is error() supposed to be called when a failure occurs? This does not seem very helpful because the participant will normally only send FAIL to the coordinator and get a FAILED response because the participant has thrown an exception. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173301#4173301 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173301

15 years, 7 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionManager and AS' ServiceBindingManager

by jhalliday

Ok, probably 4713 and 4714 then, to make them consecutive with the existing 4712 usage. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173286#4173286 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173286

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Management operation over JBM 2 Core API

by timfox

I would suggest a slight change to the way this works. We could have some kind of special "hard coded" management address, there's no actual real queue bound). You then send a management message to that address, in the management message you send, you add a header "REPLY_DESTINATION" (or whatever). The server processes the request and sends reply back to REPLY_DESTINATION. Being able to specify REPLY_DESTINATION is more flexible since it allows you to say, send responses to global queue or topic where they are processed by some other consumers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173273#4173273 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173273

15 years, 7 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

"bstansberry(a)jboss.com" wrote : I can blog about it when I get back, or, Galder if you feel like blogging, go for it; you did most of the work and can rightly take the glory if you wish. I can look into this next week and send you a draft. I'd like to publish on my newly created blog in which i was planning to create a jboss category, so this would be a good way to kick off that category :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173272#4173272 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173272

15 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2008