Word-wrap message type and destination address

[dannycohen]

The page also has some issues with long endpoint and message type names:

[gbiellem]

Hi @dannycohen

• "large numbers" is a bit vague.
• Also what do you mean by "adjustable"

Is there something more specific in a requirements issue we can refer to?

[gbiellem]

Hi @sergio are you working on this now? If so we should mark the issue as in progress and I'll add it to a milestone

[sergioc]

Hi @gbiellem yes, thanks - marked as "in progress"

[dannycohen]

@gbiellem - Good points, Let me clarify and illustrate in writing:

Adjustable for large numbers of failed messages

Its difficult to pin down a number, but consider a classic scenario:

1. Endpoint X is has a throughput of 100 msg/sec
2. The endpoint relies on an external web service to complete its processing of a message
3. The external web service fails for 5 mins
4. Within those 5 mins, there were 30,000 messages that failed processing in endpoint X

So the number can basically be any large number, depending on system throughput
and downtime of its varying components.

Adjustable for significant variety in numbers of message types, endpoints, hosts

@sergioc and I discussed "Adjustable" in the UI sense of being able to present varying numbers of items.
For example:

• For large numbers of failed messages, an adjustable UI would be either the current add-messages-on-scroll-down behavior (as in SP Failed Messages page), or paging (as in SI)
• For large numbers of endpoint instances (lets assume 10s or even ~100) the display may be expand/collapse (e.g. "show all / show less" etc.) or any other option.
  • For example, IMO, @sergio suggestion of placing the filter bar on the left side opens up support for displaying many entities for filtering selection).
  • This would not be as easy to do if the same filter bar would be placed at the top of the page

Thoughts ?

[udidahan]

Please take into account the issue of deserialization failures described in https://github.com/Particular/Requirements/issues/58

[gbiellem]

@dannycohen Which requirements does this link to? I know we've has some meeting on moving this forward prior to the new requirements process but at the moment this activity is under the radar and we should try and get it into the pipeline properly

[sergioc]

@gbiellem @indualagarsamy would it be useful to also indicate which is the endpoint / instance that sent a specific message that failed?

[cjoergensen]

Hi

The page also has some issues with long endpoint and message type names:

[jinskeep]

I want to second what cjoergensen posted. our ServicePulse looks just like this as most our endponts have really long names. Having a UI that is more flexible would be greatly appreciated.

[johnsimons]

@cjoergensen @jinskeep we are considering adding the ellipses in the middle, do you think that would work for you ?
So an example, instead of:
My.Super.Super.Very.Very.Long.Namespace...
it would be:
My.Super...MyMessageName