[JBossWS] - Re: WS-Addressing in native stack
by mobaxkrs
Thanks for the response
I upgraded jbossWS 3.1.0 GA
I tried to use wsconsume.sh to generate the stub classes,
also wsrunclient.sh to check.
Now i get a different error.
anonymous wrote :
| root@mobax0159:~/jboss-4.2.3.GA/bin# ./wsconsume.sh -k -v http://200.201.202.159:8080/SampleWebService/SampleWebService?wsdl
| parsing WSDL...
|
|
| Error: Could not import. (use --verbose to see full traces)
| java.lang.NoSuchMethodError: org.w3c.dom.Document.setDocumentURI(Ljava/lang/String;)V
| at com.sun.tools.ws.wsdl.parser.DOMForest.parse(DOMForest.java:197)
| at com.sun.tools.ws.wsdl.parser.DOMForest.parse(DOMForest.java:147)
| at com.sun.tools.ws.wsdl.parser.MetadataFinder.parseWSDL(MetadataFinder.java:102)
| at com.sun.tools.ws.wsdl.parser.WSDLParser.parse(WSDLParser.java:141)
| at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:126)
| at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:182)
| at org.jboss.ws.tools.jaxws.impl.SunRIConsumerImpl.consume(SunRIConsumerImpl.java:230)
| at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(WSConsume.java:222)
| at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:80)
|
oh God. Will i complete this?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220800#4220800
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220800
17 years, 1 month
[JBoss Cache: Core Edition] - putForExternalRead doesn't solve our problem
by jshowalter
After porting to 3.0.0.GA and putForExternalRead, it turned out we hadn't read the fine print, which says nothing happens if the node is already there (not the data itself--the node containing the data--we had misread the Javadocs).
Because we have more than one piece of data stored in a node, the node is often there even though some data is not.
So, puts of data weren't happening when we wanted them to, and the cache was returning nulls instead of data fetched to fill the node after a cache miss.
We realize this is by design and documented as such, but the design puzzles us. The put should succeed if the node is there but the key for the data being put is missing, and should succeed if the node and key are there but the value in the node for that key is null.
We are, after all, trying to do a cache fill after a cache miss. A fill that doesn't fill isn't very useful.
Furthermore, if all of the data in a node ages out of the cache due to LRU, is the data removed from the cache and the node left in place, or is the node also removed? Because if the node is not removed, then PFER wouldn't work in that case either (which makes the design even more puzzling to us).
JBoss support's suggestion was that we mimic PFER ourselves, which was what we had originally asked for help with, but when it got to the part about suspending transactions ourselves, that's when we said we're using JPA and the JPA spec says we'll go to JPA jail if we try to muck with transactions at all while being managed by the container. So that's not an option.
For now, we're hoping changing the isolation level to READ_COMMITTED from the default helps. If not, we'll have to lengthen the timeout.
Ideally JBoss Cache would have a method with a better name than putFastForCacheFillFromExternalReadAfterCacheMissEvenIfNodeIsPresent, but with that semantics.
The behavior of PFFCFFERACMEINIP would be remarkably similar to the behavior of PFER, except for modifying the first bullet in the Javadocs:
- Only goes through if the node specified does not exist, or exists but does not have the specified key for the value being put, or exists and has the specified key for the value being put but the value is null.
- Force asynchronous mode for replication to prevent any blocking.
invalidation does not take place.
- 0ms lock timeout to prevent any blocking here either. If the lock is not acquired, this method is a no-op, and swallows the timeout exception.
- Ongoing transactions are suspended before this call, so failures here will not affect any ongoing transactions.
- Errors and exceptions are 'silent' - logged at a much lower level than normal, and this method does not throw exceptions.
However, it occurs to us that the folks at hibernate.org seem plenty satisfied with the current behavior of PFER, and their use case is basically the same as our use case, which gets us to wondering why they're happy and we're not.
Is our problem due to storing multiple items per node by key? If so, we could change to storing each item in a separate node. That seemed expensive (a lot of maps), but maybe that's how this is supposed to work?
If so, we have a followup question--currently when we invalidate data locally (to force a cache miss and cache fill on the next access to that data), we just clear the data in a node, but leave the node in place. Are we supposed to invalidate by deleting the node itself? If so, how does *that* work when multiple threads are trying to access the same node? Won't readers back up behind a write lock, thereby re-introducing the very problem we were trying to solve with PFER in the first place? (Puts due to cache misses on reads timing out because of contention for write locks.)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220791#4220791
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220791
17 years, 1 month
[JBoss jBPM] - Re: Exception-Handler an Transitions
by kukeltje
ok, for the 'intimi': I stil had to respond BEFORE going to sleep.
the
anonymous wrote : No, it is clear (to me ;-))
is 'vague' because I'm a non-native English speaker.. ahh no, it was just vage.. sorry. I combined the answer to the first and second question...
now the real response
| (01:11:56) Me, Myself and I: one thing... I do not understand your response about exceptionhandling
| (01:12:16) bradatamentra: i was saying i didnt get your response
| (01:12:19) bradatamentra: either
| (01:13:11) Me, Myself and I: The action in the exception-handler is the exception..... meaning that in THAT kind of exceptions you cannot put the token anywhere. I should have mentioned that if that is what you mean
| (01:13:55) Me, Myself and I: and yes... nested exceptions between the java code and the engine are not possible
| (01:14:11) bradatamentra: so the action handler in my exception-handler
| (01:14:15) bradatamentra: why cant that move the process?
| (01:14:21) bradatamentra: or it can?
| (01:14:33) bradatamentra: gosh, i dont get it... i have read that section of docs many times
| (01:14:39) Me, Myself and I: no it can't afaik... because you are on a different level
| (01:14:43)] bradatamentra: just trying it for the first time this week on client side
| (01:15:26) Me, Myself and I: compare it to starting a program from a shell script. If the program throws an error, you are back in your shell script and cannot influence the program anymore since it 'crashed'
| (01:16:23) bradatamentra: i just think the doc is a bit contradictory. it says you cant at first, but you can.... i dont understand why you couldnt since you could get the root token and move it to a given node
| (01:17:11) bradatamentra: i figured what they were saying is in jbpm, the exeception handling doesnt mean the actual token is moving into the global exception handler... but just that the actions would be applied from the global exception handler to the token at the point the exception occurred
| (01:17:38) bradatamentra: and in that sense, the flow of control is not working like it does in java.... where you can use the scope of the exception to determine flow control
| (01:18:18) bradatamentra: instead they are saying you could use an action to determine flow control, but otherwise no flow control changes are made for handled exceptions
| (01:19:29) Me, Myself and I: Yes in that sense it sounds contradictory... but your analysis is good
And yes, that was 1.19:29 local time... 1 hour before the chat ended and even then it took me 20 minutes to cut/paste this response... should have started from scratch
If it is still not clear, please comment
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220790#4220790
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220790
17 years, 1 month