[Design of JBoss ESB] - Re: JBoss Remoting Gateway using bogus HttpMarshaller?
by Kevin.Conner＠jboss.com
"tfennelly" wrote : Anyway. I think we can work around it for now and provide backward compatibility for anyone using JBR as a Http client in production (nuts, but I suppose it is possible :) ).
Nuts perhaps, but safer than breaking code which is already working :)
At least it will give us some breathing space until the underlying issue is fixed.
"tfennelly" wrote : The HttpMarshaller executes on the same thread as the InvocationHandler (in our case the JBossRemotingGateway). If we attach the InvocationRequest object to the thread from inside the JBossRemotingGateway, we can then access it from inside the HttpMarshaller. In the HttpMarshaller, we can check:
|
| 1. Are we talking to a Remoting Client (set in the request metadata).
| 2. Is the response payload a Binary Payload type (set in the response metadata).
| 3. Is the response object an InvocationResponse (passed to the HttpMarshaller).
|
| If all of the above are "true", we unwrap the InvocationResponse and write the wrapped payload. We do this because under these conditions the JBR client will assume (incorrectly) that the payload is not an InvocationResponse and will attempt to read it as a raw stream of bytes.
|
| This is not fool proof because we have no guaranteed way of serializing the underlying payload to bytes, but we didn't before this either, so we're no worse off :)
It does sound scary but, if it leaves the clients unchanged we should at least try it. As you say, we are no worse off than previously and, hopefully, it will be stable enough until the underlying cause is addressed.
Thanks Tom, this looks like a good compromise.
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236652#4236652
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236652
16 years, 7 months
[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?
by camunda
By the way: Biggest issue I have with it is, that then you have to work with a RemoteCommandExecutor instead of a CommandService (the real interface).
In my app I want to use the CommandService (interfcae), not knowing that a RemoteCommandService sits behind it. Would be possible with EJB 3 out of the box, without using the "EjbRemoteCommandService" wrapper...
For the EjbRemoteCommandService I have a question: Why is the InitialContext created every time I execute a command (isn't that expensive?)? Should be improved I think (lazy create it once).
And why can't it read the jndi.properties from the classpath as an alternative?
Can I improve that class a bit? If you don't use it in the ProcessEngine wiring but directly from a remote client, it is not that nice this way...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236647#4236647
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236647
16 years, 7 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Journal Cleanup and Journal Compactor
by timfox
As far as I am concerned, compacting solves all these issues.
We *definitely* need to do compacting, and *maybe* we need to do linked list (although I think that is doubtful).
So we should do compacting first, then, if there are problems with that approach we can look at linked list, but linkedlist is not a priority right now.
Let me describe how I think the compacting should work.
Let's say we have a set of files in the journal:
F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
min files is set to 10
The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
The actual compacting approach goes as follows:
The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
When this process is finished it will end up with, say, two new files containing the compacted records.
We can then save a marker file (empty in the journal directory) which says we are starting the rename.
The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
Then the two new files need to be renamed so they will be picked up by the journal.
When that process completes the marker file can be deleted.
If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
This ensures the journal will still startup after such a crash.
Also the JournalFile objects also need to be updated in memory when the compact is complete.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236630#4236630
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236630
16 years, 7 months
[Design of JBoss ESB] - Re: JBoss Remoting Gateway using bogus HttpMarshaller?
by tfennelly
This has always been an issue. I guess we just didn't come across the right combination to produce it.
Anyway. I think we can work around it for now and provide backward compatibility for anyone using JBR as a Http client in production (nuts, but I suppose it is possible :) ).
The HttpMarshaller executes on the same thread as the InvocationHandler (in our case the JBossRemotingGateway). If we attach the InvocationRequest object to the thread from inside the JBossRemotingGateway, we can then access it from inside the HttpMarshaller. In the HttpMarshaller, we can check:
1. Are we talking to a Remoting Client (set in the request metadata).
2. Is the response payload a Binary Payload type (set in the response metadata).
3. Is the response object an InvocationResponse (passed to the HttpMarshaller).
If all of the above are "true", we unwrap the InvocationResponse and write the wrapped payload. We do this because under these conditions the JBR client will assume (incorrectly) that the payload is not an InvocationResponse and will attempt to read it as a raw stream of bytes.
This is not fool proof because we have no guaranteed way of serializing the underlying payload to bytes, but we didn't before this either, so we're no worse off :)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236628#4236628
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236628
16 years, 7 months