[Design of POJO Server] - JBVFS-25 - Optimizing the VFS PathTokenizer
by adrian＠jboss.org
It looks to me that the problem with the PathTokenizer
(and the related findChild() is all the string comparisons.
| public static String[] getTokens(String path)
| {
| if (path == null)
| throw new IllegalArgumentException("Null path");
|
| StringTokenizer tokenizer = new StringTokenizer(path, "/");
| int count = tokenizer.countTokens();
| if (count == 0)
| return null;
|
| String[] tokens = new String[count];
| int i = 0;
| while (tokenizer.hasMoreTokens())
| {
| String token = tokenizer.nextToken();
|
| if ("".equals(token))
| throw new IllegalArgumentException("A path element is empty: " + path);
|
| tokens[i++] = token;
| }
| return tokens;
| }
|
| /**
| * Is current token.
| *
| * @param token the token to check
| * @return true if token matches current path token
| */
| public static boolean isCurrentToken(String token)
| {
| return CURRENT_PATH.equals(token);
| }
|
| /**
| * Is reverse token.
| *
| * @param token the token to check
| * @return true if token matches reverse path token
| */
| public static boolean isReverseToken(String token)
| {
| return REVERSE_PATH.equals(token);
| }
|
1) If StringTokenizer was replaced with an optimized lexer
(e.g. like the one used to parse system property references from strings in common-core)
then the check for an empty token could be done inline instead of string
comparison.
2) Similarly the usage of "." and ".." as tokens could be optimized to
return the singleton reference of these strings in the token array.
The code then check for object equality, e.g.
| public static boolean isCurrentToken(String token)
| {
| -- return CURRENT_PATH.equals(token);
| ++ return CURRENT_PATH == token;
| }
|
It's worth while optimizing this code since it is showing up as a hotspot.
It will be hotspot at runtime as well (not just boot time) since this code
gets invoked on every classloading request (that isn't to a previously cached
or blacklisted class) - since the classloader uses the VFS.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152255#4152255
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152255
17 years, 10 months
[Design of JBoss ESB] - FS-listener IOException
by ama1
Hi,
I have a problem with the FS-Listener, I plan to read a xml-file and want to output the content on the command line.
Here is my jboss-esb.xml:
<?xml version="1.0" encoding="UTF-8"?>
| <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml..."
| parameterReloadSecs="5"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xsi:schemaLocation="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml...
|
| D:\Tools\jbossesb-server-4.3.CR1\docs\schema\jbossesb-1.0.1.xsd">
| <providers>
| <fs-provider name="file_inbound">
| <fs-bus busid="inbound_channel">
| <fs-message-filter directory="d:/temp/inbound"
| input-suffix=".xml"
| work-suffix=".esbInProcess"
| post-delete="false"
| post-directory="d:/temp/inbound"
| post-suffix=".sentToEsb"
| error-delete="false"
| error-directory="d:/temp/inbound"
| error-suffix=".IN_ERROR"/>
| </fs-bus>
| </fs-provider>
|
| </providers>
| <services>
| <service category="myCategory" name="HOH" description="Hand-Off-Handler">
| <listeners>
| <fs-listener name="File-Gateway"
| busidref="inbound_channel"
| maxThreads="1"
| is-gateway="false"
| poll-frequency-seconds="5"/>
| </listeners>
|
| <actions>
| <action name="action2" class="org.jboss.soa.esb.actions.SystemPrintln">
| <property name="printfull" value="true"/>
| </action>
| </actions>
| </service>
| </services>
| </jbossesb>
|
But I getting this error in the server log:
| 2008-05-21 11:13:38,128 DEBUG [org.jboss.internal.soa.esb.couriers.FileCourier] No valid work suffix found in EPR - using default of .esbInProcess
| 2008-05-21 11:13:48,128 DEBUG [org.jboss.internal.soa.esb.couriers.FileCourier] FileCourier.pickup caught exception during readOneMessage: org.jboss.soa.esb.couriers.CourierMarshalUnmarshalException: java.io.IOException
|
What is wrong???
Unfortunaly the log messages are not very verbose.
Thanks for any help!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152251#4152251
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152251
17 years, 10 months
[Design of JBoss ESB] - Re: JCRMessageStoreImpl store only message body?
by maeste
"michael.neale(a)jboss.com" wrote : Hmm... I would think JCR maybe not the right persistence mechanism for large amounts of transactional data - it certainly is suited for heterogenous message payloads, but it is generally more about content then billions of little messages.
|
Ok, and what else do you have in mind? Relational DB? HDFS?
We can evaluate to leave data in these repository, write a DNA connector and view them with federation engine "as if it's in JCR".
For sure I'll make a first (easier) implementation of JCR message store, and I'll focus on sequencer, but other solution for storing and then federate them can be evaluated in next future.
So, what do you think is the best store for ESB message?
My 2c:
1) JCR could have limitation with large amounts of messages, not with big messages, it would be quite easy to configure and deploy. Moreover with DNA a 100% JBoss solution could be implemented ;)
2) Relational DB. No problem with large number of messages, maybe some problem with very very large messages. It is a well known technology, probably customers have at least one installation in their server farms. Heterogeneity of data may be an issue, even if we consider DNA federation the only (or at least the main) solution to intercat with data it would be a secondary problem (IOW brute storing data and leaving DNA the responsibility to make them able to be queried).
3) HDFS. A lot of benefits storing data (as far as I understood it, studing it too fewer to feel me confident): distributed, high available, fast(?), no problem for tons of file, no problem with huge files. What are the minus in my opinion? Not so easy to install and maintain (from customer point of view), another API to implement on both side (ESB and DNA federation). May be the best solution at long term, would be not so easy as starting point, it should be on our road map, but IMHO not at short terms.
But one more time my question is: does it make some sense to keep this large amount of data for a long time for all? I think, the best approach, would be to have more than one repository available for different purpose (and I think ESB already have both solution 1 and 2, even if they can be revisited as I'm saying in this 3ad).
A JCR implementation keeping data for a relative short period of time with governance goals in mind would be an useful kick start.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152219#4152219
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152219
17 years, 10 months
[Design of JBoss ESB] - Re: Support marshaling or unmarshaling the soap message us
by jim.ma
"jeffdelong" wrote : For 1) can you describe what the rest of the configuration would look like, i.e. the provider and listener? What would com.foo.Request and com.foo.Response look like?
|
When publish a ESB service to Web service , we can just simply keep the provider and listener as is and add the inClass/outClass and faultClass attribute to
Actions element , for example this is the configuration for publish helloworld esb service:
| <?xml version = "1.0" encoding = "UTF-8"?>
| <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml..." parameterReloadSecs="5">
|
| <providers>
| <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
| <jms-bus busid="quickstartGwChannel">
| <jms-message-filter
| dest-type="QUEUE"
| dest-name="queue/quickstart_helloworld_Request_gw"
| />
| </jms-bus>
| <jms-bus busid="quickstartEsbChannel">
| <jms-message-filter
| dest-type="QUEUE"
| dest-name="queue/quickstart_helloworld_Request_esb"
| />
| </jms-bus>
|
| </jms-provider>
| </providers>
|
| <services>
| <service
| category="FirstServiceESB"
| name="SimpleListener"
| description="Hello World">
| <listeners>
| <jms-listener name="JMS-Gateway"
| busidref="quickstartGwChannel"
| maxThreads="1"
| is-gateway="true"
| />
| <jms-listener name="helloWorld"
| busidref="quickstartEsbChannel"
| maxThreads="1"
| />
| </listeners>
| <actions inClass="com.foo.Request" outClass="com.foo.Response">
| <action name="action1"
| class="org.jboss.soa.esb.samples.quickstart.helloworld.MyJMSListenerAction"
| process="displayMessage"
| />
| <action name="action2" class="org.jboss.soa.esb.actions.SystemPrintln">
| <property name="printfull" value="true"/>
| </action>
| <!-- The next action is for Continuous Integration testing -->
| <action name="testStore" class="org.jboss.soa.esb.actions.TestMessageStore"/>
| </actions>
| </service>
| </services>
|
| </jbossesb>
com.foo.Request and com.foo.Response can be like this :
public class Request implements Serializable {
| public String msg ;
| }
|
| public class Response implements Serializable {
| public String msg;
| }
If the "inClass" attribute is defined , Request and Response class will be used to generate schema and generate wsdl during the service starts up . Other artifacts will also be generated , for example endpoint
implementation class used to publish web service to jbossws stack .
"jeffdelong" wrote :
| For 2) what would be supported from the SOAP Header, e.g. ws-security or ws-transaction information?
|
We can support them. And the extra effort we need to do is writing our own processor or translator to convert the soap header to our esb message header format.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152200#4152200
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152200
17 years, 10 months