I have written some code that sends off a large number of JMS
objectMessages to a queue which can then decode the message scan the
content and choose to do two things:
send a new message back into the queue (URLIdentify)
or send it to a new queue (ContentIdentify)
When I run this using the default connection factories for OIL
(ConnectionFactory) or (XAConnectionFactory) I eventually end up having
all my ports on my machine being locked off by the Optimized Invocation
Layers send/receive ports.
I had resolved some other lock conflicts with a JDBC call that I first
thought was the problem. The queues are standard and im using jboss
3.0.4T on jdk1.4.1_01 on winXP talking to SQL server 2K using the inet
opta drivers.
The messagedriven ejb have pretty standard config. Transaction set to
Is there any way to curb this or has anyone came across a solution to
this problem?
I have tried all the other invocation layers esp the JVM one but that
seems to be upto twice as slow yet the docs say its defintely faster if
the application resides in the same jvm and it does, why does it take so
much longer?
Can someone please help me make my deadline please or Im in serious
sh*t.
P.S. one other problem is that when deploying I never seem to find the
queueconnectionfactory resource, is this a problem? And would this cause
all these problems? :)
Thanks.
Michael
>>> deploy log
18:47:50,828 WARN [MessageDrivenContainer] No resource manager found
for ConnectionFactory
18:47:50,828 INFO [JMSContainerInvoker] Starting
>>>>>>>>>>>>>>>>>URLIdentify MDB Xdoclet config
@ejb:bean name="URLIdentifyMessageHandler"
*
display-name="URLIdentifyMessageHandler"
* transaction-type="Container"
* acknowledge-mode="Auto-acknowledge"
* destination-type="javax.jms.Queue"
* subscription-durability="NonDurable"
*
* @ejb:transaction type="Supports"
*
* @jboss:destination-jndi-name
"queue/vamosa/identify/URLIdentifyMessageQueue"
* @ejb:resource-ref res-ref-name="ConnectionFactory"
res-type="javax.jms.QueueConnectionFactory" res-auth="Container"
* @ejb:resource-ref res-ref-name="jdbc/Powerbuild"
res-type="javax.sql.DataSource" res-auth="Container"
*
* @ejb:ejb-ref ref-name="Project" ejb-name="Project"
view-type="local"
* @ejb:ejb-ref ref-name="PBObject"
ejb-name="PBObject" view-type="local"
* @ejb:ejb-ref ref-name="MetaDataValue"
ejb-name="MetaDataValue" view-type="local"
* @ejb:ejb-ref ref-name="MetaDataAttribute"
ejb-name="MetaDataAttribute" view-type="local"
* @ejb:ejb-ref ref-name="MetaDataClass"
ejb-name="MetaDataClass" view-type="local"
*
*/
The content identify is almost identical except the names have been
changed.
The messageDrivenContext for the beans is like so:
....
queueConnectionFactory = (QueueConnectionFactory)
ctx.lookup("java:/ConnectionFactory");
ContentMessageQueue = (Queue)
ctx.lookup("queue/vamosa/identify/ContentIdentifyMessageQueue");
ContentMessenger = new
ContentIdentifyMessageSender(queueConnectionFactory,
ContentMessageQueue,new
Integer(GUIDGenerator.getGenerator().getNextIntGUID()));
.....
The contentMessenger authenticates to the queues as guest,guest on both
message senders.
And finally my messagedriven configuration in the standard-jboss.xml
look like this.
.....
<container-invoker-conf>
<JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI>
<ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI>
<MaximumSize>100</MaximumSize>
<MaxMessages>5</MaxMessages>
<MDBConfig>
<ReconnectIntervalSec>10</ReconnectIntervalSec>
<DLQConfig>
<DestinationQueue>queue/DLQ</DestinationQueue>
<MaxTimesRedelivered>10</MaxTimesRedelivered>
<TimeToLive>0</TimeToLive>
</DLQConfig>
</MDBConfig>
</container-invoker-conf>
<container-pool-conf>
<MaximumSize>100</MaximumSize>
<strictMaximumSize>true</strictMaximumSize>
</container-pool-conf>
</container-configuration>
I have tried to manipulate this a bit to try and help and also tried the
strictmaximumsize value to force a limit but to no avail.
========================================================================
=======================
-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
