[Design of JBossCache] - Re: Evolution of TcpDelegatingCacheLoaders/TcpCacheServers
by akluge
Hi,
The test setup is using a one cache (L1) connected to a separate
cache (L2) with TcpDelegatingCacheLoader. The second cache is
of course running with a TcpCacheServer.
When I refer to a cache miss, I am speaking of performing a get for
key that does not exist in the L1 cache. The get request is intercepted,
as it should be, by the CacheLoaderInterceptor.
The visitGetKeyValueCommand method is invoked, and it has the full
get command (most importantly, it has the Fqn and the key). The
Fqn and the key are passed to the loadIfNeeded method, along with
false for the allKeys parameter. So far, everything looks reasonable.
However, the loadIfNeeded method does not directly use the allKeys
parmater, it simply passes it on to the mustLoad method, and doesn't
concern us any further.
As expected, mustLoad returns true if the key is not in the cache,
and the loadIfNeeded method then loads the entire node from the loader,
which in this case results in the entire node being loaded across the
network. This request is delegated to the relevant loader, in this case a
TcpDelegatingCacheLoader.
This is clearly the way that JBossCache is designed, as the
CacheLoader interface defines only a get(Fqn) method, and no
get(Fqn, key). The question is, why was this design decision made?
Is there something that depends on this behavior?
This really hurts in terms of scalability. I an looking at replacing
the interceptor and the loader eventually so that a get does not attempt
to load an entire segment of the cache as it does now.
Thanks,
Alex
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235869#4235869
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235869
16 years, 6 months
[Design of JBoss jBPM] - Re: samplePU
by Tar_Szator
I tried the same errors, but only from
anonymous wrote : [start-jboss] 12:08:11,906 ERROR [STDERR] 62 [main] WARN org.jboss.resteasy.plugins.server.servlet.R
| esteasyBootstrap - The use of javax.ws.rs.core.Application is deprecated, please use javax.ws.rs.App
| lication as a context-param instead
|
till
anonymous wrote : 19:52:11,210 ERROR [STDERR] 240 [main] INFO org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap - Adding singleton resource org.jboss.bpm.console.server.UserMgmtFacade from Application javax.ws.rs.core.Application
I used JBoss-5.1.0.Ga and jbpm-4.0.CR1. To deploy jbpm I used "ant install.jbpm.into.jboss"
Exists a solution for this problem?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235845#4235845
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235845
16 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Measuring server performance
by timfox
I added a couple of undocumented features to the server that are useful in getting readings of server performance, they just need to be added in jbm-configuration.xml:
log-journal-write-rate true/false - if true then the server will log out its journal write rate in real time in bytes/sec to stdout. This is useful to see just how fast the journal is really going.
And a new one:
perf-blast-pages - if this is specified then, immediately after startup, the server will do a self performance test, blasting the journal with records in a loop, to see how fast it can really go. The journal record size is always currentBufferSize (since this gives the best performance) - (we could add a parameter to specify the blast buffer size too).
The number of pages is the number of buffers (flushes) it does in the loop.
Trying this on both my laptop and messaging01 gives great results:
Here's some output from messaging-01:
| [java] 05:58:23,130 INFO [org.jboss.messaging.core.asyncio.impl.TimedBuffer] Write rate = 1.4141455538694993E8 bytes / sec
| [java] 05:58:25,158 INFO [org.jboss.messaging.core.asyncio.impl.TimedBuffer] Write rate = 1.3275241025641026E8 bytes / sec
| [java] 05:58:27,134 INFO [org.jboss.messaging.core.asyncio.impl.TimedBuffer] Write rate = 1.3100566801619433E8 bytes / sec
| [java] 05:58:29,162 INFO [org.jboss.messaging.core.asyncio.impl.TimedBuffer] Write rate = 1.5828171992110455E8 bytes / sec
| [java] 05:58:31,138 INFO [org.jboss.messaging.core.asyncio.impl.TimedBuffer] Write rate = 1.2397447773279352E8 bytes / sec
| [java] 05:58:33,166 INFO [org.jboss.messaging.core.asyncio.impl.TimedBuffer] Write rate = 1.4451528205128205E8 bytes / sec
| [java] 05:58:35,142 INFO [org.jboss.messaging.core.asyncio.impl.TimedBuffer] Write rate = 1.2052521457489878E8 bytes / sec
| [java] 05:58:37,170 INFO [org.jboss.messaging.core.asyncio.impl.TimedBuffer] Write rate = 1.3036105719921105E8 bytes / sec
| [java] 05:58:39,146 INFO [org.jboss.messaging.core.asyncio.impl.TimedBuffer] Write rate = 1.3664388663967611E7 bytes / sec
|
|
|
I.e. we get around 140 MiBytes per sec. Which is almost saturating the very fast server disks.
In practice when sending/consuming real messages we never get beyond around 50MiB, so this tells us we can optimise a lot more!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235821#4235821
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235821
16 years, 6 months
[Design of JBoss ESB] - Problems with transmitting content from ESB to jBPM via jBPM
by andreskusa
Hi there,
this is a question about the JbpmCallback action provided by the jBPM version that is shipped with the JBoss ESB (in these tests I'm using ESB 4.4 and the contained jBPM 3.2.2 in a JBoss AS 4.2.3). I'm applying this action in order to get back from the ESB to a running process instance in jBPM. In ESB 4.4 I could also have applied the BpmProcessor service with the "SignalCommand" property for this purpose, but since this is not supported anymore in ESB 4.5 (and presumably in future version) I was looking for something general that hopefully stays.
To get back and forth between jBPM and ESB via JbpmCallback works fine (after one finds out that the necessary process information is expected in the message at Message.getHeader().getCall().getTo(), instead of getRepyTo() ...), but what did not work for me yet is to bring new data with the message into the process.
Specifically, I start the process (named "AccountingStandardProcess") from within the ESB like that (in the jboss-esb.xml):
<action name="startProcessInstance" class="org.jboss.soa.esb.services.jbpm.actions.BpmProcessor">
|
| <property name="command" value="StartProcessInstanceCommand" />
| <property name="process-definition-name" value="AccountingStandardProcess"/>
| <property name="esbToBpmVars">
| <mapping esb="messageContent" bpm="bpmMessageContent" />
| <mapping esb="settingsESB" bpm="bpmSettingsESB" />
| </property>
|
| </action>
|
| So, there are two parts of the message body, messageContent and settingsESB, which are mapped into the jBPM context. This works fine, the bpm-Objects are existing within jBPM, can be modified there and are correctly returned if I call the ESB again via the ESBActionHandler (processdefintion.xml):
<node name="Call AccountingDelegateService in ESB" async="true">
| <action class="org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
| <esbCategoryName>Accounting</esbCategoryName>
| <esbServiceName>AccountingDelegateService</esbServiceName>
|
| <bpmToEsbVars>
| <mapping bpm="bpmMessageContent" esb="messageContent" />
| <mapping bpm="bpmSettingsESB" esb="settingsESB" />
| </bpmToEsbVars>
|
| <!--
| <esbToBpmVars>
| <mapping esb="messageContent" bpm="bpmMessageContent" />
| <mapping esb="settingsESB" bpm="bpmSettingsESB" />
| </esbToBpmVars>
| -->
|
| </action>
| </node>
|
| As you can see, a part of this is commented. For just getting back to the ESB, the bpmToEsbVars mapping is enough. When I leave jBPM, the token stays at this node shown here, and gets back to it after calling JbpmCallback in jboss-esb.xml:
<action name="prepareCallbackMessage" class="com.wincornixdorf.icash.datasupplier.esb.actions.PrepareMessageForCallback"/>
|
| <action name="jbpmCallback" class="org.jboss.soa.esb.services.jbpm.actions.JBpmCallback">
| <property name="esbToBpmVars">
| <mapping esb="messageContent" bpm="bpmMessageContent" />
| <mapping esb="settingsESB" bpm="bpmSettingsESB" />
| </property>
| </action>
First, my action PrepareMessageForCallback just copies the "replyTo" object of the header into the "To" object (as described above). Then JbpmCallback jumps back and the process runs to its end without problems.
BUT:
The data in messageContent has been changed meanwhile (in the ESB) and I need it also in the process. If I do it like that, even if I also have such a mapping in the ESBActionHandler (commented lines above), the new content is not copied into the process.
I tried also to give the jbpm variables new names when calling JbpmCallback, e.g.:
| <property name="esbToBpmVars">
| <mapping esb="messageContent" bpm="bpmMessageContent2" />
| <mapping esb="settingsESB" bpm="bpmSettingsESB2" />
| </property>
|
in order to access the changend content at a new name in jBPM, but this resulted in a runtime error which sounded somehow like that he was not able to create these variables at this stage.
So I guess, context variables in jBPM are only created at the start of the process, not when getting back to a running instance. This would make sense, but why can't I transmit changed message data when re-entering? Did I miss something or isn't this possible in principle? If not, this would be a hard restriction for using a combination of jBPM and the ESB.
Looking forward to your help,
Andre Skusa, Wincor Nixdorf, Germany
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235798#4235798
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235798
16 years, 6 months