Spring JMS sorun giderme kılavuzu

Bu makalede, Spring JMS kullanırken bilinen sorunları ve yaygın hataları giderme adımları açıklanmaktadır. Makale, spring-cloud-azure-starter-servicebus-jmshakkında sık sorulan bazı soruları da yanıtlar.

Bağlantı sorunları

MessageProducer kurtarılamaz bir hata nedeniyle kapatıldı

Sorun açıklaması

İleti göndermek için JmsTemplate kullanırken, JmsTemplate 10 ile 15 dakika arasında boşta kalma süresi boyunca kullanılamaz duruma gelir. Bu aralıkta ileti göndermek, aşağıdaki örnek çıktıda gösterilen özel durumları alabilir:

2022-11-06 11:12:05.762  INFO 25944 --- [   scheduling-1] c.e.demo.ServiceBusJMSMessageProducer    : Sending message: 2022-11-06T11:12:05.762072 message 1
2022-11-06 11:12:05.772 ERROR 25944 --- [   scheduling-1] o.s.s.s.TaskUtils$LoggingErrorHandler    : Unexpected error occurred in scheduled task

org.springframework.jms.IllegalStateException: The MessageProducer was closed due to an unrecoverable error.; nested exception is javax.jms.IllegalStateException: The MessageProducer was closed due to an unrecoverable error.
    at org.springframework.jms.support.JmsUtils.convertJmsAccessException(JmsUtils.java:274) ~[spring-jms-5.3.23.jar:5.3.23]
  ...
Caused by: org.apache.qpid.jms.provider.ProviderException: The link 'G0:36906660:qpid-jms:sender:azure:5caf3ef4-9602-413c-964d-cf1292d6e1f5:1:1:1:t4' is force detached. Code: publisher(link376). Details: AmqpMessagePublisher.IdleTimerExpired: Idle timeout: 00:10:00. [condition = amqp:link:detach-forced]
    at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToNonFatalException(AmqpSupport.java:181) ~[qpid-jms-client-0.53.0.jar:na]
  ...

Neden analizi

AMQP bağlantısı ve bağlantısı etkinken arama olmadığında (örneğin, arama gönderme veya alma) 10 dakika boyunca bağlantı kullanılarak yapıldığında Azure Service Bus özel durumlar oluşur. Bu durumda bağlantı kapatılır. Etkinlik olmadığı (boşta) ve 5 dakika içinde yeni bir bağlantı oluşturulmadığı için bağlantıdaki tüm bağlantılar kapatıldığında bağlantı kapatılır.

Service Bus JMS başlatıcısı için, oturumu, üreticiyi ve tüketiciyi önbelleğe alan CachingConnectionFactory varsayılan olarak kullanılır. JmsProducer 10 dakikadan uzun ancak 15'ten kısa bir süre boşta kaldığında, önbelleğe alınan üreticinin kapsadığı bağlantı kapatılır. İletiler bu aralıkta gönderilemiyor. Ardından, 5 dakika daha boşta kaldıktan sonra tüm bağlantı kapatılır. Bu nedenle, 15 dakikalık boşta kalma aralığından sonraki herhangi bir gönderme işlemi, CachingConnectionFactory gönderilecek yeni bir bağlantı oluşturmasına neden olur. Gönderme işlemi 15 dakika sonra kullanılabilir hale gelir.

Geçici çözüm

Şu anda starter, havuzların JmsPoolConnectionFactory, Connectionve Sessionhavuzlarını oluşturan ve havuza alınan örneklerin yaşam döngüsünü yöneten MessageProduceruygulayarak bağlantı ayırma sorunu için geçici bir çözüm sağlar. Bu geçici çözüm, bir üreticinin kullanılamadıktan sonra çıkarılmasını ve bu nedenle tüm gönderme işlemlerinin etkin üreticiler üzerinde gerçekleştirilmesini sağlayabilir.

Bu geçici çözümü kullanmak için aşağıdaki yapılandırmayı ekleyin:

spring:
  jms:
    servicebus:
      pool:
        enabled: true
        max-connections: ${your-expected-max-connection-value}

Kullanımı: spring.jms.servicebus.idle-timeout

Boşta kalma zaman aşımı özellikleri, AMQP bağlantısının boşta zaman aşımı yapılandırır. AMQP belirtimi aşağıdaki açıklamayı sağlar:

Bağlantılar boşta kalma zaman aşımı eşiğine tabidir. Eşik değeri aşıldıktan sonra çerçeve alınmadığında zaman aşımı yerel bir eş tarafından tetiklenir. Boşta kalma zaman aşımı milisaniye cinsinden ölçülür ve son çerçevenin alındığı zamandan itibaren başlar. Eşik aşılırsa eş, nedenini açıklayan bir hatayla yakın bir çerçeve kullanarak bağlantıyı düzgün bir şekilde kapatmayı denemelidir. Uzak eş buna eşik içinde düzgün bir şekilde yanıt vermezse, eş TCP yuvasını kapatabilir.

Bir JMS istemcisi için, bu özelliği yapılandırdığınızda, sunucu tarafında hiçbir ileti teslim edildiğinde bağlantının canlı kalmasını sağlamak için sunucunun boş bir çerçeve göndermesini ne kadar bekleyeceğinizi denetlersiniz. Bu özellik uzak eş davranışını denetler ve her eş kendi yalıtılmış değerine sahip olabilir.

JmsTemplate sorunları

Zamanlanmış iletiler

Azure Service Bus gecikmeli ileti işlemeyi destekler. Daha fazla bilgi için İleti sıralama ve zaman damgalarıZamanlanmış iletiler bölümüne bakın. JMS için, bir ileti zamanlamak için ScheduledEnqueueTimeUtcileti ek açıklaması üst bilgisini kullanarak x-opt-scheduled-enqueue-time özelliğini ayarlayın.

JmsListener sorunları

Sunucuda ileti olmamasına rağmen Service Bus'a çok fazla istek gönderiliyor

Sorun açıklaması

@JmsListener API'sini kullanırken, bazı durumlarda Azure portalında, sunucuda alacak ileti olmasa bile kuyruğuna veya konu başlıklarına gönderilen gelen istekler için sürekli değerler olduğunu görebilirsiniz.

Neden analizi

@JmsListener, yinelenen yoklama girişimleri için oluşturulmuş bir yoklama dinleyicisidir.

Dinleyici, devam eden bir yoklama döngüsünde yer alır. Her döngü, yerel tüketiciyi iletilerin tüketmesi için yoklama yapmak için JMS MessageConsumer.receive() yöntemini çağırır. Varsayılan olarak, her yoklama işlemi için yerel tüketici, ileti istemek için ileti aracısına çekme istekleri gönderir ve ardından belirli bir süre için engeller. Beton yoklama işlemi, receiveTimeout, prefetchSizeve receiveLocalOnly veya receiveNoWaitLocalOnlygibi çeşitli özelliklerle belirlenir. receiveNoWaitLocalOnly yöntemi yalnızca receiveTimeout negatif bir değere ayarladığınızda kullanılır.

Bu sorun uygulamanıza oluştuğunda aşağıdaki yapılandırma ayarlarını denetleyin:

• Ön ilkenizin varsayılan seçenek olan 0 olup olmadığını belirleyin. 0-prefetch, her anket için Service Bus'a çekme istekleri gönderen bir çekme tüketicisi anlamına gelir.

• Sıfır olmayan bir ön koşul yapılandırdıysanız, receiveLocalOnly veya receiveNoWaitLocalOnly özelliğinizin varsayılan seçenek olan falseolarak ayarlanıp ayarlanmadığını belirleyin. Burada false bir değer, yalnızca yerel tüketiciyi yoklamadığından sunucuya çekme istekleri gönderilmesine neden olur.

• receiveTimeout yapılandırması, her çekme isteğinin ne kadar süreyle engelleneceğini belirler, bu nedenle sunucuya gönderilen çekme isteklerinin sıklığını etkileyebilir. Varsayılan değer 1 saniyedir.

Tam bir analiz içinGitHub sorunundaki tartışmaya bakın.

Çözümleri

Aşağıdaki bölümlerde bu sorunla başa çıkmak için iki çözüm açıklanmaktadır

Çözüm 1. Tüketiciyi göndermek ve yalnızca yerel denetim yapmak için değiştirin

Modu pusholarak değiştirerek tüketici, aracıdan ileti çekmeyen ancak hedef miktarda bağlantı kredisi tutan Zaman Uyumsuz Bildirim tüketicisi olur. Tutar, bir prefetch özelliği tarafından belirlenir. Service Bus (gönderen) iletileri gönderirken, gönderenin bağlantı kredisi azalır ve gönderenin bağlantı kredisi eşiğin altına düştüğünde, istemci (alıcı) gönderenin bağlantı kredisini istenen hedef tutara geri döndürmek için sunucuya bir istek gönderir.

Bu çözümü gerçekleştirmek için aşağıdaki yapılandırmayı ekleyin:

İlk olarak, prefetch numarasını sıfır olmayan olarak yapılandırın; bu da tüketiciyi çekme dışı olarak yapılandırılır. Aşağıdaki tabloda, her biri farklı Service Bus varlıklarını denetleyen çeşitli prefetch özellikleri gösterilmektedir. Servis talebinize uygulanacak özellikleri ayarlayın.

İkinci olarak, aşağıdaki örnekte gösterildiği gibi fabrika özelleştiricisi için bir yapılandırma sınıfı ekleyerek non-local-check yapılandırın:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

    @Bean
    ServiceBusJmsConnectionFactoryCustomizer customizer() {
        return factory -> {
            factory.setReceiveLocalOnly(true);
            // Configure the below ReceiveNoWaitLocalOnly instead if you have specified the property 
            // spring.jms.listener.receive-timeout with negative value. Otherwise, configure the above `ReceiveLocalOnly`.
            //factory.setReceiveNoWaitLocalOnly(true);
        };
    }
}

Ön koşul değeri, iletilerin tüketicinin yerel arabelleğine ne kadar hızlı gönderildiğini etkileyebilir. Değeri tüketen performansınıza ve ileti birimlerinize göre ayarlamanız gerekir. Uygun bir değer, tüketen işlemi hızlandırabilirken, çok büyük bir değer yerel olarak arabelleğe alınan iletilerin güncel olmasına ve yeniden gönderilmesine neden olabilir. Her iletinin işlenmesinin uzun sürdüğü düşük ileti birimleri için, ön işlemi 1 olarak ayarlayın. Bu değer, tüketicinin bir kerede yalnızca bir iletiyi işlemesini sağlar.

Çözüm 2. Çekme sıklığını azaltmak için alma zaman aşımını artırın

Alma zaman aşımı özelliği, tüketicinin çekme sonucunu ne kadar süreyle bekleyeceğine ilişkin stratejiyi belirler. Bu nedenle, zaman aşımını genişleterek çekme sıklığını azaltabilir ve ardından çekme modunu seçtiğinizde çekme isteklerinin sayısını azaltabilirsiniz. Aşırı durumlarda, bir ileti gelene kadar süresiz bekleme stratejisini ayarlayabilirsiniz; bu da tüketicinin yalnızca bir iletiyi kullandıktan sonra çekmesi anlamına gelir. Bu durumda, sunucuda ileti olmadığında beklemeyi engeller.

Bu çözümü gerçekleştirmek için spring.jms.listener.receive-timeout özelliğini yapılandırın. Bu özellik java.time.Duration türündedir ve varsayılan değeri 1 saniyedir. Aşağıdaki listede çeşitli değerlerin etkisi açıklanmaktadır:

• Alma zaman aşımının 0 olarak ayarlanması, bir ileti dağıtılana kadar çekme işleminin süresiz olarak engellendiği anlamına gelir.
• Alma zaman aşımını pozitif bir değere ayarlamak, çekme işleminin zaman aşımı süresine kadar engel olduğu anlamına gelir.
• Alma zaman aşımını negatif bir değere ayarlamak, çekme işleminin beklemeyen bir alma olduğu anlamına gelir; bu da hemen bir ileti döndürdüğü veya kullanılabilir ileti yoksa null anlamına gelir.

Ayrıca kapsayıcı yalnızca receive-timeout aralığı geçtikten sonra istek gönderebilir. Aralık 10 dakikadan uzunsa, Service Bus bağlantıyı kapatır ve dinleyicinin göndermesini veya almasını engeller. Daha fazla bilgi için Azure Service BusAMQP hatalarının Bağlantısı kapatıldı bölümüne bakın. Dinleyici varsayılan olarak CachingConnectionFactorykullanır.

Yüksek bir alış zaman aşımına ihtiyacınız varsa JmsPoolConnectionFactorykullandığınızdan emin olun.

Bağlantı kapatma sorunu ve JmsPoolConnectionFactorykullanma hakkında daha fazla bilgi için messageproducer kurtarılamaz bir hata nedeniyle kapatıldı bölümüne bakın.

Önceden yükleme sorunu

Sorun açıklaması

Uygun olmayan bir ön koşul ilkesi aşağıdaki sorunlara neden olabilir:

• Aynı iletiler tekrar tekrar tüketilir.
• İletiler hata veya özel durum olmadan işlendiğinde bile MaxDeliveryCountExceededsonra teslim edilemeyen ileti kuyruğuna alınır.

Neden analizi

Bu sorun genellikle değer gerçek tüketen kapasiteden yüksek olduğunda prefetch ve yerel arabelleğe çok fazla iletinin tüketilmeyi beklemesi etkisiyle ortaya çıkar. Ancak, önceden oluşturulmuş iletiler Service Bus tarafından bir peek-lock modda gönderildi olarak görüntülenir. Dağıtılan her iletinin bir max-delivery-count ve lock-duration öznitelikleri vardır. peek-lock Alma modunda, ön yakalama arabelleğine getirilen iletiler kilit için zaman aşımı saati işaretleyerek kilit durumunda arabelleğe alınır. Ön işlem arabelleği büyükse ve işlem o kadar uzun sürüyorsa, ileti kilitlerinin süresi ön koşul arabelleğinde kalırken sona erer, ileti terk edilmiş olarak değerlendirilir ve kuyruktan alınmak üzere yeniden kullanılabilir hale gelir.

Bu sorun, iletinin ön yakalama arabelleğine alınmasına ve sonuna yerleştirilmesine neden olabilir. İleti süresi dolmadan önce ön işlem arabelleği işlenmezse, iletiler tekrar tekrar önceden eklenir ancak kullanılabilir (geçerli olarak kilitlenmiş) bir durumda hiçbir zaman etkili bir şekilde teslim edilmez. Ardından, bu eski kopyalar sıralandığında, uygulama aynı iletiyi tekrar tekrar tüketir ve tamamlayamaz. Başka bir durumda, yinelenen iletilerin tümü arabellekte tüketilmeden önce sona erer. Bu durumda, Service Bus'taki ileti, teslim sayısı üst sınırı aşıldıktan sonra sonunda teslim edilemeyen ileti kuyruğuna taşınır.

Daha fazla bilgi için Prefetch neden varsayılan seçenek değildir bakın. Azure Service Bus iletileriniönceden bölümü.

Çözüm

Kullanım özelliğine uyduğundan emin olmak için prefetch yapılandırmasına dikkat edin. Ön işlem sayısı üst sınırını ve kuyrukta veya abonelikte yapılandırılan kilit süresini, kilit zaman aşımının en az ön yükleme arabelleğinin maksimum boyutu için beklenen toplu ileti işleme süresini ve bir iletiyi aştığı şekilde dengelemeniz gerekir. Aynı zamanda, kilit zaman aşımı, iletilerin yanlışlıkla bırakıldığında yaşam süresi üst sınırını aşması ve böylece yeniden teslim edilmeden önce kilitlerinin süresinin dolmasını gerektirmesi gibi uzun olmamalıdır.

Varsayılan değeri sıfır olan prefetch özniteliğini yapılandırmak için aşağıdaki özelliklerden birini kullanın:

Service Bus'a AMQP dağıtımı nasıl yapılır?

JMS, mesajlaşma aracısına ileti onaylarken beş AMQP değerlendirme türünü destekler. Desteklenen değerler ACCEPTED, REJECTED, RELEASED, MODIFIED_FAILEDve MODIFIED_FAILED_UNDELIVERABLE'dır. Daha fazla bilgi için Azure Service Bus standart ve AMQP 1.0ile Java message Service 1.1 kullanma AMQP dağıtımı ve Service Bus işlem eşlemesi bölümüne bakın.

Bu nedenle, JmsListenerkullanarak iletiyi el ile tamamlamak, bırakmak, teslim edilemeyen harfi ertelemek veya serbest bırakmak için aşağıdaki adımları kullanın:

1. Oturum işlemeyi devre dışı bırakın ve client ack modunu kullanın.

   Bu görevi gerçekleştirmek için kendi JmsListenerContainerFactory bean bildirin ve ardından özellikleri ayarlayın ya da JmsListenerContainerFactoryiçinde tanımlanan işlemi gerçekleştirin. Aşağıdaki örnek, başka bir fasulye bildirme yaklaşımını kullanır:

   @Configuration(proxyBeanMethods = false)
   public class CustomJmsConfiguration {
   
       @Bean
       public JmsListenerContainerFactory<?> customQueueJmsListenerContainerFactory(
               DefaultJmsListenerContainerFactoryConfigurer configurer, ConnectionFactory connectionFactory) {
           DefaultJmsListenerContainerFactory jmsListenerContainerFactory = new DefaultJmsListenerContainerFactory();
           configurer.configure(jmsListenerContainerFactory, connectionFactory);
           jmsListenerContainerFactory.setPubSubDomain(Boolean.FALSE);
           jmsListenerContainerFactory.setSessionTransacted(Boolean.FALSE);
           jmsListenerContainerFactory.setSessionAcknowledgeMode(Session.CLIENT_ACKNOWLEDGE);
           return jmsListenerContainerFactory;
       }
   }
   

2. İleti işleyicinizde iletileri açıkça tamamlayın veya bırakın.

   @JmsListener(destination = "QUEUE_NAME", containerFactory = "customQueueJmsListenerContainerFactory")
   public void receiveMessage(JmsTextMessage message) throws Exception {
       String event = message.getBody(String.class);
       try {
           logger.info("Received event: {}", event);
           logger.info("Received message: {}", message);
           // by default complete the message
           message.acknowledge();
       } catch (Exception e) {
           logger.error("Exception while processing re-source event: " + event, e);
           JmsAcknowledgeCallback acknowledgeCallback = message.getAcknowledgeCallback();
           // explicitly abandon the message
           acknowledgeCallback.setAckType(MODIFIED_FAILED);
           message.setAcknowledgeCallback(acknowledgeCallback);
           message.acknowledge();
           throw e;
       }
   }
   

Yapılandırma sorunları

Service Bus JMS otomatik yapılandırmayı devre dışı bırakma

Sorun açıklaması

Bazı kullanıcılar, Service Bus JMS dışında bir Azure hizmetinin otomatik yapılandırması için spring cloud Azure Starter'ı içeri aktarır. Ayrıca Service Bus JMS'ye gerek kalmadan Spring JMS çerçevesini de kullanırlar. Ardından, uygulama başlamaya çalıştığında aşağıdaki özel durumlar oluşturulur:

Caused by: java.lang.IllegalArgumentException: 'spring.jms.servicebus.connection-string' should be provided
    at com.azure.spring.cloud.autoconfigure.jms.properties.AzureServiceBusJmsProperties.afterPropertiesSet(AzureServiceBusJmsProperties.java:210)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1863)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1800)
    ... 98 more

Neden analizi

Bu sorun, tüm Spring Cloud Azure otomatik yapılandırma sınıflarının aynı modüle yerleştirilmesinden kaynaklandığından, tüm Spring Cloud Azure Starter aslında Service Bus JMS'yi de içeren tüm otomatik yapılandırmayı içeri aktarır. Ardından uygulama Spring JMS API'sini kullandığında Service Bus JMS otomatik yapılandırma koşulunu karşılar ve tetikler. Ardından, spring-cloud-azure-starter-servicebus-jmskullanmayı amaçlamayan kullanıcılar için özellik koşulları karşılanmaz çünkü JMS için Service Bus'ı yapılandırmaları için bir neden yoktur. Bu durum özel durumların atılması neden olur.

Çözüm

Service Bus için Spring Cloud Azure JMS, otomatik yapılandırmayı açmak veya kapatmak için bir özellik sağlar. Aşağıdaki özellik ayarını kullanarak bu işlevi gerektiği gibi devre dışı bırakabilirsiniz:

spring.jms.servicebus.enabled=false

İleti özniteliklerini yapılandırma

Giden iletilerin içerik türü nasıl ayarlanır?

İçerik türünü yapılandırmak için İleti Dönüştürücüsü'nü özelleştirerek iletileri dönüştürürken içerik türü özniteliğini değiştirin. Aşağıdaki kod, bayt iletilerini örnek olarak alır.

İlk olarak, aşağıdaki örnekte gösterildiği gibi JmsTemplateiçinde kullanılacak ileti dönüştürücüsİnİ özelleştirin:

public class CustomMappingJackson2MessageConverter extends MappingJackson2MessageConverter {

    public static final String CONTENT_TYPE = "application/json";

    public CustomMappingJackson2MessageConverter() {
        this.setTargetType(MessageType.BYTES);
    }

    @Override
    protected BytesMessage mapToBytesMessage(Object object, Session session, ObjectWriter objectWriter)
            throws JMSException, IOException {
        final BytesMessage message = super.mapToBytesMessage(object, session, objectWriter);
        JmsBytesMessage msg = (JmsBytesMessage) message;
        AmqpJmsMessageFacade facade = (AmqpJmsMessageFacade) msg.getFacade();
        facade.setContentType(Symbol.valueOf(CONTENT_TYPE));
        return msg;
    }
}

Ardından, bu örnekte gösterildiği gibi özelleştirilmiş ileti dönüştürücü çekirdeğinizi bildirin:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

    @Bean
    public MessageConverter messageConverter() {
        return new CustomMappingJackson2MessageConverter();
    }
}

MappingJackson2MessageConverter için tür kimliği özellik adı nasıl ayarlanır?

type-id-property-name özniteliği, MappingJackson2MessageConverter ileti yükünü seri durumdan çıkarmak için hangi sınıfın kullanılacağını belirlemesini sağlar. Her Java nesnesini spring message yüküne seri hale getirdiğinizde, dönüştürücü yük türünü type-id-property-nametarafından kaydedilen özellik adıyla bir ileti özelliğinde depolar. Ardından, iletiyi seri durumdan çıkarırken, dönüştürücü iletiden tür kimliğini okur ve seri durumdan çıkarma gerçekleştirir.

type-id-property-nameayarlamak için, aşağıdaki örnekte gösterildiği gibi kendi MappingJackson2MessageConverter fasulyenizi bildirin ve bu özelliği yapılandırın:

@Configuration(proxyBeanMethods = false)
public class CustomJmsConfiguration {

    @Bean
    public MessageConverter jacksonJmsMessageConverter()
    {
        MappingJackson2MessageConverter converter = new MappingJackson2MessageConverter();
        converter.setTypeIdPropertyName("your-custom-type-id-property-name");
        return converter;
    }
}

Yinelenen algılama

Azure Service Bus, iletileri benzersiz olarak tanımlamak ve Service Bus'a gönderilen yinelenenleri atmak için özelliğini uygulayanyinelenen algılamayı destekler.

Ancak JMS API'si için JMS belirtimlerinde geçersiz olarak kabul edilen JMS ileti kimliğini ayarlamamalısınız. Bu nedenle bu özellik şu anda Spring Cloud Azure Service Bus JMS Starter için desteklenmemektedir.

Bu özellik hakkında daha fazla güncelleştirme içinGitHub sorununa bakın.

AMQP aktarım günlüğünü etkinleştirme

Daha fazla bilgi için service bus sorunlarını gidermeAMQP aktarım günlüğünü etkinleştirme bölümüne bakın.

Ek yardım alın

Destek için ulaşma yolları hakkında daha fazla bilgi için deponun kökündeki Destek bakın.

Spring Cloud Azure Service Bus JMS starter kaynakları

• JMS ile Azure Service Bus kullanma
• Azure Service Bus erişmek için Spring'de JMS kullanma
• Spring Cloud Azure 4.0 için Geçiş kılavuzu
• Örnek

GitHub sorunlarını dosyalama

GitHub sorunlarını bildirirken aşağıdaki ayrıntılar istenir:

• Service Bus yapılandırması / Ad alanı ortamı
  • Ad alanı (standart veya premium) hangi katmandır?
  • Hangi tür mesajlaşma varlığı kullanılıyor (kuyruk veya konu)? ve yapılandırması.
  • Her iletinin ortalama boyutu nedir?
• Trafik düzeni nasıldır? (diğer bir ifadeyle dakika başına ileti sayısı ve İstemcinin her zaman meşgul olup olmadığı veya trafik dönemlerinin yavaş olup olmadığı.)
• Yeniden oluşturma kodu ve adımları
  • Bu, sorunu genellikle ortamımızda yeniden oluşturamadığımız için önemlidir.
• Günlük