Scenario:
I'm using NServiceBus with MSMQ Transport.
I have messages from an app dropped into QUEUE-A.
I have a NServiceBus Gateway grab messages from QUEUE-A and send them to another Gateway
I the Destination Gateway receives the messages and places them into the respective queue.
Source Gateway throws a Null Reference Exception and send the messages 5 total times (max retries).
Destination Gateway receives all messages and shows that it's Sending the HTTP response in the log.
The error that the Destination Gateway throws is:
WARN NServiceBus.Unitcast.Transport.Msmq.MsmqTransport [(null)] <(null)> - Failed raising 'transport message received' event for message with ID=GUID
System.NullReferenceException: Object reference not set to an instance of an object.
This error initially was setup on 2 different servers though it occurs when I run the scenario locally, under admin rights, on my local computer (just listening on different ports). I'm setting the SetHttpToHeader() of the message to the proper destination address.
The gateway configs are as follows:
Gateway1:
<appSettings>
<add key="NumberOfWorkerThreads" value="10"/>
<add key="InputQueue" value="Gateway1Pickup"/>
<add key="ErrorQueue" value="Gateway1Error"/>
<add key="ForwardReceivedMessageTo" value="audit"/>
<add key="OutputQueue" value="Gateway1Output"/>
<add key="ListenUrl" value="http://address:6768/Gateway/"/>
<add key="RequireMD5FromClient" value="true"/>
</appSettings>
Gateway2:
<appSettings>
<add key="NumberOfWorkerThreads" value="10"/>
<add key="InputQueue" value="Gateway2Pickup"/>
<add key="ErrorQueue" value="Gateway2Error"/>
<add key="ForwardReceivedMessageTo" value="audit"/>
<add key="OutputQueue" value="Gateway2Output"/>
<add key="ListenUrl" value="http://address:6768/Gateway/"/>
<add key="RequireMD5FromClient" value="true"/>
</appSettings>
Does anyone know where I'm going wrong on this?
At first I got a solid repro and then I realized that NSB does not handle creating the Audit queues for you. If you remove them from the config or create the Audit queues, you should be all set.
I found this above problem showed up when I didn't have some dependent assemblies in the service directory. I found the error attached to the message in the MSMQ queue. I used Queue Explorer, but I presume other tools would show the same.
Related
I'm attempting to get a basic layout up and running in Sitecore 8.1, and I've hit an error about which I can find very little information. When attempting to view any page (even the backend interface or connecting from Sitecore Rocks), I get the message "No session Id managers were found to manage the session Id for the current request."
Some Googling suggests that this has to do with some issues with the out-of-box session provider and recommends swapping it out for keeping the sessions in Mongo. Sitecore's documentation provides a description of this, both for shared and private sessions. I've attempted to implement those but continue to receive the same error.
Here's my code as it stands now:
App_Config/Include/MongoSessionProvider.config
<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<tracking>
<sharedSessionState>
<providers>
<clear/>
<add name="mongo" type="Sitecore.SessionProvider.MongoDB.MongoSessionProvider, Sitecore.SessionProvider.MongoDB" connectionString="session" pollingInterval="2" compression="true" sessionType="shared"/>
</providers>
</sharedSessionState>
</tracking>
</sitecore>
</configuration>
App_Config/Include/ConnectionStrings.config (excerpt)
<add name="session" connectionString="mongodb://localhost/sharedsession" />
Web.config (excerpt)
<sessionState mode="Custom" cookieless="false" timeout="20" sessionIDManagerType="Sitecore.FXM.SessionManagement.ConditionalSessionIdManager" customProvider="mongo">
<providers>
<add name="mongo" type="Sitecore.SessionProvider.MongoDB.MongoSessionStateProvider, Sitecore.SessionProvider.MongoDB" sessionType="Standard" connectionStringName="session" pollingInterval="2" compression="true" />
<add name="mssql" type="Sitecore.SessionProvider.Sql.SqlSessionStateProvider, Sitecore.SessionProvider.Sql" sessionType="Standard" connectionStringName="session" pollingInterval="2" compression="true" />
</providers>
</sessionState>
Note that this is on my local development machine. I have Mongo running (and confirmed its connection to Sitecore), and I created both the session and sharedsession databases in it using use session and use sharedsession, which I understand to be the way to create DBs in Mongo.
Am I missing something here? Or does the error simply not mean what I think it means?
The message you are seeing is not supposed to be an error, it is rather a log warning. It is related to retrieving the configuration of the Session ID Manager rather that to the configuration of the session itself.
Why this warning normally appears
In the Sitecore.config under <pipelines> there's the getSessionIdManager pipeline defined.
<getSessionIdManager>
</getSessionIdManager>
In the Sitecore.FXM.config, there is a processor configured for this pipeline:
<getSessionIdManager>
<processor type="Sitecore.FXM.Pipelines.ChooseSessionIdManager.FXMSessionIdManagerProcessor, Sitecore.FXM" />
</getSessionIdManager>
This pipeline allows to dynamically select a Session ID Manager for the request. In the default Sitecore configuration, a non-default Session ID Manager will be used only for requests with explicit sessionId URL parameter, i.e. for FXM requests only.
For all other requests, no Session ID Manager will be explicitly selected, and the default System.Web.SessionState.SessionIDManager will be used; this is reflected in the warning message you're seeing. There is nothing wrong with this situation per se, this is by default and by design.
Seeing the message as an error on every page request
This definitely sounds like a defect to me. This message is supposed to be logged once per application lifetime instead of being thrown as an exception on every page.
You should report this to Sitecore support.
An attempt to fix
I cannot debug your system, so I have to do this blindfolded. I would try to create you own Session ID Manager selector:
public class CustomSessionIdManagerProcessor
{
public void Process(GetSessionIdManagerArgs args)
{
if(args.SessionIdManager == null)
{
args.SessionIdManager = new System.Web.SessionState.SessionIDManager();
}
}
}
Configure it as the last processor in the getSessionIdManager pipeline. This will make sure that there is always an explicitly selected Session ID Manager and should hopefully prevent the error from happening.
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<pipelines>
<getSessionIdManager>
<processor type="YourNamespace.CustomSessionIdManagerProcessor, YourAssembly" />
</getSessionIdManager>
</pipelines>
</sitecore>
</configuration>
In case it helps anyone else, we were running into this issue as well after upgrading to Sitecore 8.1 rev. 151003.
In our particular case the issue was with a namespace change in this line in the Web.config:
<sessionState mode="InProc" cookieless="false" timeout="20"
sessionIDManagerType="Sitecore.FXM.SessionManagement.ConditionalSessionIdManager">
That should be the following:
<sessionState mode="InProc" cookieless="false" timeout="20"
sessionIDManagerType="Sitecore.SessionManagement.ConditionalSessionIdManager">
It might have been something we missed in the upgrade guide, but we finall found it after pulling down the a copy of Sitecore 8.1 rev. 151003.zip from the downloads page.
When an exception occurs in the code that's called from the handler, the host tries it for 5 times and then shuts down the service with the following message:
2013-10-17 08:57:12,091 [13] FATAL NServiceBus.Faults.Forwarder.FaultManager [(null)] - Could not forward failed message to error queue.
Autofac.Core.Registration.ComponentNotRegisteredException: The requested service 'NServiceBus.Transports.ISendMessages' has not been registered. To avoid this exception, either register a component to provide the service, check for service registration using IsRegistered(), or use the ResolveOptional() method to resolve an optional dependency.
2013-10-17 08:57:12,139 [13] FATAL NServiceBus [(null)] - Fault manager failed to process the failed message with id e0fc75b2-4eef-4f90-a450-a25901130c9a
System.InvalidOperationException: Could not forward failed message to error queue. ---> Autofac.Core.Registration.ComponentNotRegisteredException: The requested service 'NServiceBus.Transports.ISendMessages' has not been registered. To avoid this exception, either register a component to provide the service, check for service registration using IsRegistered(), or use the ResolveOptional() method to resolve an optional dependency.
Here's my config:
<configSections>
<section name="MessageForwardingInCaseOfFaultConfig" type="NServiceBus.Config.MessageForwardingInCaseOfFaultConfig, NServiceBus.Core" />
<section name="UnicastBusConfig" type="NServiceBus.Config.UnicastBusConfig, NServiceBus.Core" />
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
</configSections>
<MessageForwardingInCaseOfFaultConfig ErrorQueue="error" />
<UnicastBusConfig ForwardReceivedMessagesTo="audit">
<MessageEndpointMappings />
</UnicastBusConfig>
Here's my Bus initialization code:
public class EndpointConfig : IConfigureThisEndpoint, AsA_Server, AsA_Publisher, UsingTransport<Msmq>
{
}
NServiceBus.SetLoggingLibrary.Log4Net(log4net.Config.XmlConfigurator.Configure);
NServiceBus.Unicast.Config.ConfigUnicastBus busConfig = Configure.With()
.Log4Net()
.DefaultBuilder()
.MsmqSubscriptionStorage()
.UnicastBus();
Bus = busConfig.CreateBus().Start(() => Configure.Instance.ForInstallationOn<NServiceBus.Installation.Environments.Windows>().Install());
I am not quite sure why it is not able to try the SLR after failing 5 times and also forwarding it to the error queue after that.
Any help is appreciated!
Thanks
Prasad
Take a look here: https://github.com/sfarmar/Samples/tree/master/HalloWorldWithPubSub
I'm hoping this can guide you in the right direction
I am using jboss-5.1 to deploy message driven bean which is used to subscribe messages from a third party queue.
Around 16 messages were posted to that queue but they remained pending in our subscriber queue. I restarted the server and the messages were readily picked.
As much as I have analysed, I think maxsize and maxsession could have affected it, as both are 15. But I do not understand if there was some real issue, how it got solved by just restarting.
The logs were in error mode. I did not get the full stack trace.
This is the snippet of that error log.
[2012-10-30 17:01:00,228] [MQQueueAgent (GQH1_PLANNING_MDM_001)]
[ERROR] STDERR: 2012.10.30 17:01:00 MQJMS1023E rollback failed
[2012-10-30 17:01:00,228] [exceptionDelivery0] [WARN ]
org.jboss.resource.adapter.jms.inflow.JmsActivation: Failure in jms activation
org.jboss.resource.adapter.jms.inflow.JmsActivationSpec#85d0d(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter#b21aae
destination=remotewsmq/NOTIFICATION_PLANNING_MDM_001.SUBQ
destinationType=javax.jms.Queue tx=true durable=false reconnect=10 provider=RemoteWSMQJMSProvider
user=null maxMessages=1 minSession=1 maxSession=5 keepAlive=60000 useDLQ=false)
GQH1_PLANNING_MDM_001: The name of the queue used for subscribing.
The files that I use to configure the properties of the MDBs are as follows.
1.ejb3-interceptors-aop.xml
<domain name="Message Driven Bean" extends="Intercepted Bean" inheritBindings="true">
<bind pointcut="execution(public * *->*(..))">
<interceptor-ref name="org.jboss.ejb3.security.AuthenticationInterceptorFactory"/>
<interceptor-ref name="org.jboss.ejb3.security.RunAsSecurityInterceptorFactory"/>
</bind>
<!-- TODO: Authorization? -->
<bind pointcut="execution(public * *->*(..))">
<interceptor-ref name="org.jboss.ejb3.tx.CMTTxInterceptorFactory"/>
<interceptor-ref name="org.jboss.ejb3.stateless.StatelessInstanceInterceptor"/>
<interceptor-ref name="org.jboss.ejb3.tx.BMTTxInterceptorFactory"/>
<interceptor-ref name="org.jboss.ejb3.AllowedOperationsInterceptor"/>
<interceptor-ref name="org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor"/>
<!-- interceptor-ref name="org.jboss.ejb3.interceptor.EJB3InterceptorsFactory"/ -->
<stack-ref name="EJBInterceptors"/>
</bind>
<annotation expr="class(*) AND !class(#org.jboss.ejb3.annotation.Pool)">
#org.jboss.ejb3.annotation.Pool (value="StrictMaxPool", maxSize=15, timeout=10000)
</annotation>
</domain>
2.standardjboss.xml
<invoker-proxy-binding>
<name>message-driven-bean</name>
<invoker-mbean>default</invoker-mbean>
<proxy-factory>org.jboss.ejb.plugins.jms.JMSContainerInvoker</proxy-factory>
<proxy-factory-config>
<JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI>
<ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI>
<CreateJBossMQDestination>false</CreateJBossMQDestination>
<!-- WARN: Don't set this to zero until a bug in the pooled executor is fixed -->
<MinimumSize>1</MinimumSize>
<MaximumSize>15</MaximumSize>
<KeepAliveMillis>30000</KeepAliveMillis>
<MaxMessages>1</MaxMessages>
<MDBConfig>
<ReconnectIntervalSec>10</ReconnectIntervalSec>
<DLQConfig>
<DestinationQueue>queue/DLQ</DestinationQueue>
<MaxTimesRedelivered>10</MaxTimesRedelivered>
<TimeToLive>0</TimeToLive>
</DLQConfig>
</MDBConfig>
</proxy-factory-config>
</invoker-proxy-binding>
<activation-config-property>
<activation-config-property-name>maxSession</activation-config-property-name>
<activation-config-property-value>15</activation-config-property-value>
</activation-config-property>
3.jms-ds.xml
<?xml version="1.0" encoding="UTF-8"?>
<connection-factories>
<!-- ==================================================================== -->
<!-- JMS Stuff -->
<!-- ==================================================================== -->
<!--
The JMS provider loader. Currently pointing to a non-clustered ConnectionFactory. Need to
be replaced with a clustered non-load-balanced ConnectionFactory when it becomes available.
See http://jira.jboss.org/jira/browse/JBMESSAGING-843.
-->
<mbean code="org.jboss.jms.jndi.JMSProviderLoader"
name="jboss.messaging:service=JMSProviderLoader,name=JMSProvider">
<attribute name="ProviderName">DefaultJMSProvider</attribute>
<attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
<attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
<attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
<attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute>
</mbean>
<!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
<tx-connection-factory>
<jndi-name>JmsXA</jndi-name>
<xa-transaction/>
<rar-name>jms-ra.rar</rar-name>
<connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
<config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
<config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
<max-pool-size>20</max-pool-size>
<security-domain-and-application>JmsXARealm</security-domain-and-application>
<depends>jboss.messaging:service=ServerPeer</depends>
</tx-connection-factory>
</connection-factories>
Please help.
If the listener did not try to reconnect, then it might be the messages pending which caused it to fail.
According to the error, a transaction ROLLBACK call failed. After the failure, the queue manager probably held those messages in an outstanding unit of work. Restarting the server would have closed the connection at which point the queue manager will have rolled back the transaction on behalf of the application. On restart, the application will create a new UOW and retrieve the messages.
Look in WebSphere MQ's queue manager error logs and global error logs to determine whether the error was caused by a resource shortage. It may be necessary to increase the size of the queue manager transaction logs or to tune transaction parameters such as MAXUOW.
You may also need to update the MQ client version or Queue Manager version. According to this Technote, WebSphere MQ JMS classes were updated as of 6.0.2.3 to fix a bug that resulted in MQJMS1023E errors. If you need to update the client version, it is available as a free download as SupportPac MQC75. A new client is able to run with any back level queue manager. After upgrading, the app benefits from the bug fixes and performance enhancements of the new client code and provides API functionality appropriate for the version of Queue Manager to which it connects. What version of WebSphere MQ JMS client is currently installed? What version of WebSphere MQ queue manager is currently installed?
I am trying to configure my message endpoint mapping in my NServiceBus configuration by sending messages from different namespaces to different endpoints.
As such, I have configured the following in my web.config:
<MessageEndpointMappings>
<add Messages="Company.Messages.Accounts" Endpoint="ServiceInput" />
<add Messages="Company.Messages.Payments" Endpoint="ServiceInput" />
<add Messages="Company.Messages.Cancellations" Endpoint="ServiceInput" />
<add Messages="Company.Messages.Notifications" Endpoint="ServiceInput" />
</MessageEndpointMappings>
However, when my application starts, I receive the following exception:
Spring.Objects.PropertyAccessExceptionsException: PropertyAccessExceptionsException (1 errors); nested PropertyAccessExceptions are:
[Spring.Core.TypeMismatchException: Cannot convert property value of type [System.Collections.Hashtable] to required type [System.Collections.IDictionary] for property 'MessageOwners'., Inner Exception: System.ArgumentException: Problem loading message assembly: Company.Messages.Payments ---> System.IO.FileNotFoundException: Could not load file or assembly 'Company.Messages.Payments' or one of its dependencies. The system cannot find the file specified.
File name: 'Company.Messages.Payments'
What I find interesting is that it seems to have found Company.Messages.Accounts but failed on the second configured line. I thought that maybe it didn't like have them all go to the same endpoint, but changing this configuration to have them go different endpoints didn't change the error message I received.
What am I doing wrong? Is it not possible to segment messages by namespace (all I have seen is by type and by assembly)?
Thanks,
Steve
NSB only supports mapping of assemblies or individual types to endpoints. Namespaces are not supported, I suggest you split you message assembly into separate assemblies for each of your endpoints.
According to this page you can specify a type:
http://docs.particular.net/nservicebus/messaging/message-owner
Specific types can be configured by using their qualified name: "namespace.type, assembly".
As of NServiceBus v3.3 namespaces can be used to filter message mappings
http://docs.particular.net/nservicebus/messaging/message-owner
We have a jboss esb server which is reading files from the file system in a scheduled way (schedule frequency of 20sec) and convert them into the esb message then we parse the message.
There are some other providers/listeners (jms) and services configured on the esb servers. When there is an error in one of the services it effects the above process. File system provider (gateway) is working fine but the jms-listener who takes the gateway messages are not working and lots of messages are accumulated in the jbm queue (jbm_msg Oracle DB table).
Here is the problem, when my server is restarted messages in the jbm-queue is parsed in the esb for just 20 seconds which is the scheduled frequency of fs-provider, never process messages again and cpu usage goes up to 100% and stays there. We believe somehow fs-providers interrupts the jms-provider.
Is there any configuration we have been missing out.
Here are the configuration files that we have:
jboss-esb.xml
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd" parameterReloadSecs="5">
<providers>
<fs-provider name="SitaIstProvider">
<fs-bus busid="gw_sita_ist" >
<fs-message-filter
directory="/ikarussita/IST/IN"
input-suffix=".RCV"
work-suffix=".lck"
post-delete="false"
post-directory="/ikarussita/IST/OK"
post-suffix=".ok"
error-delete="false"
error-directory="/ikarussita/IST/ERR"
error-suffix=".err"/>
</fs-bus>
</fs-provider>
<jms-provider name="SitaESBQueue" connection-factory="ConnectionFactory">
<jms-bus busid="esb_sita_queue">
<jms-message-filter dest-type="QUEUE" dest-name="queue/esb_sita_queue"/>
</jms-bus>
</jms-provider>
</providers>
<services>
<service category="SITA" name="SITA_IST" description="SITA Daemon For ISTCOXH">
<listeners>
<fs-listener name="Sita_Ist_Gateway" busidref="gw_sita_ist" is-gateway="true" schedule-frequency="20" />
<jms-listener name="Jms_Sita_EsbAware" busidref="esb_sita_queue" />
</listeners>
<actions mep="OneWay">
<action name="parse_msg" class="com.celebi.integration.action.sita.inbound.SitaHandler" process="parseMessage" />
<action name="send_ikarus" class="com.celebi.integration.action.ikarus.outbound.fis.FlightJmsSender" />
</actions>
</service>
</services>
</jbossesb>
jbm-queue-service.xml
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=esb_sita_queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
<server>
deployment.xml
<jbossesb-deployment>
<depends>jboss.messaging.destination:service=Queue,name=esb_sita_queue</depends>
</jbossesb-deployment>
Thanx
Split the service into 2 separate services, one handling the JMS queue, the other the file poller. Specify the same action pipeline. That way you get the same functionality but without the threading issue. Also use max-threads attr on the listener to specify the number of reading threads.