The guide in question would be:

Implementing and Administering Avaya Aura Media Server

search for this on support.avaya.com

Look in the section: Security configuration....Importing a trust certificate to the trust store

The "was set trace" command settings should definitely be taking effect when that command completes. If you give it malformed values, however, those will be silently ignored. To see which ones are in effect run "was show trace".



We technically don't allow use of the WAS console, nor the setting of JVM parameters. But you've found a way that might work. I say might, because we normally fix the WAS JVM parameters during start up time, and changed whether we honored the console settings at different times and in different releases.



To verify that they are taking effect, use the "ps" command to see what arguments are being passed to the WAS JVM. A convenient shortcut is "was ps" (it knows which process is actually the was JVM).

These levels can be set through the "was set trace" command. The "ce logon" command actually uses the "was set trace" command to do its work.

ce logon

# is the same as

was set trace on



# To see the options available to the "was set" command

was help

.....

  set|show|save|edit  various parameters

      console [on|off]      enable/disable outside access to mgmt console

      heap MB-value         JVM heap size -- deprecated

      jvm                   JVM parameters

      ports TCP/UDP-value TLS-value

                            SIP Container listen ports

      pmi none|basic|extended|all 

                            Performance measurement level

      sip                   SIP Container properties

      trace on|calls|off|value 

			    Debug/Trace level

      verbosegc on|off     JVM verbose garbage collection

....



# The form

was set trace value 

# is what you want.  For your case:



was set trace "*=info:com.ibm.ws.sip.*=all:com.ibm.wsspi.sip*=all:com.ibm.ws.udp.*=all:com.ibm.websphere.security.*=all:com.ibm.ws.ssl.*=all"



# will augment the normal "ce logon" values with the two others about which you asked

Even the GigaSpaces metrics should be available from the cust login.

-gs metrics are provided only when run on the server that is running the first look-up service (normally the first node added to the cluster). Try the -gsc option (which -ALL does not use) to see them from any node.

If you still don't see the values, please raise a ticket.

From the Breeze command line (shell) run the "metget" command. It has many options, but to see the number of active subscriptions, you'd use:

metget -gs Subscription

and get output like:

67 GS.Objects.CECommonSpace.breeze2-mgmt.PRIMARY.Subscription
67 GS.Objects.TOTAL.CECommonSpace.Subscription

metget -? shows all the options.

metget -ALL shows all the possible current metric values (it's slow--depending on what's loaded there are over 25,000 different metrics).

You can form your own grep pipeline or use the one that's built in (like above with the word "Subscription").

metget also has some "canned" queries that can be viewed with "metget -l"

The metric names should hint at what they are counting. For the -was metrics a google search of WebSphere perfmon can help explain more about them.

The Collaboratory service which you are using does not support the changing of the text to speech voice. Rest assured, however, that when you purchase your own Nuance server you will be able to make those changes. Refer to the following DevConnect FAQ to learn how this is done:

https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_experience_portal/support/faq/configuring_asr_tts_servers.gsp

The From: and ReplyTo: addresses are set by the proper methods on the EmailRequest class. The account (user) and password used to login to the email sending server is only specified in the connector's attributes. Some email servers restrict the From: address to be the same as the account, though usually not the ReplyTo. If the From or ReplyTo is not specified in the EmailRequest, then the connector's Default Sender's or Reply To settings are used. If there is no default From (and no From in the EmailRequest) an error will be posted.

Most email sending servers have tightened their security requirements, so that they allow sending only as the logged in user. You'll have to negotiate with your sending server provider if you want to send as others from a single account. The default email connector can login only as a single account. If you have more than one account you'll need either to write your own email connector or use the JavaMail API (https://java.net/projects/javamail/pages/Home) from your snap-in directly (the default email connector uses JavaMail).

We have found that restrictions on ReplyTo have not been tightened, and you're more free to put other addresses there.

This message is coming back from the SMTP server. You'll need to work with the owner of that server to determine why the account you send from has no permissions. Using "tshark" to take a trace of the session that the EmailConnector creates should help. On the Breeze node, run: tshark -i eth1 -w /tmp/mail.pcap tcp port 25

Send your test email. It will be queued, but should send out to the email server within 60 seconds. If you don't see packets exchanged within this time, try tshark -i eth0

Also you should upgrade to Breeze 3.2.

We encourage you to use the Eclipse plugin that can be installed with the Avaya Breeze SDK. It offers single click access to the steps you are currently manually running. What makes this work quickly, and not get in the way of the normal Breeze service audit, is that it bypasses System Manager (when it can) by installing the svar directly on the Breeze node and directly into the JEE container. The heart of this process is the deploy_service script that you've discovered.

However, deploy_service is pretty simplistic when it comes to error reporting. All it does is tail the alog (i.e. the JEE container info/error log) and if it sees anything happening at all, assumes it's an error and lists out the nearly coincident messages. If other things are going on in WebSphere it may dump those entries too, and deploy_service thinks those are errors. The standard install run from System Manager uses deploy_service too, but instead of looking at those log entries it waits to see if the service actually starts (deploy_service -lv will show this), and declares success if it does. This is a relatively slow process, and humans (really just software developers) normally don't want to wait that long.

So, you have a choice: ignore the "errors" and assume everything worked (true 99.9% of the time) or manually run deploy_service -lv and notice that your snap-in is running, before you test. The "errors" are only a problem if your snap-in fails to start running. And, all "running" means is that your snap-in's init() method has been called and did not return an error. There still could be all kinds of problems with your snap-in's code, but that's for you to fix (and the logs displayed by deploy_service might help diagnose, though the other logs described in the troubleshooting guide are a better bet).

If you make any changes to the properties.xml file, then you must load the snap-in through the System Manager at least once. After that, as long as you confine your changes to code, you can use the faster technique described here. The Eclipse plugin checks this, and will automatically do this for you.

Several hundred metric values from the OS, JEE container (where the snap-in runs), datagrid, and database can be dumped using the metget command. metget -? should list it's usage. Some of the metric names are obvious, but most are not. Our current container is IBM WebSphere, and many of those metrics are explained in the WebSphere 8.5.5 PMI articles which show up from most web searches.

This will cover thread and cpu usage and intra-container resource usage (e.g. SIP Application Sessions). Breeze runs on Linux, so most of the OS tools (e.g. ps, vmstat, iostat, sar, top) can be used for gross CPU and memory measurements.

For Java memory usage:

"ce wasgclogc" will dump the last several hours (if very busy) or years (if not busy) WebSphere JVM garbage collection entries. From this you can calculate frequency and pauses (similar to jstat for OpenJDK).

IBM has several valuable tools you can search and download. The ultimate tool for memory leak analysis is using the Eclipse Memory Analysis Tool (or MAT) on a heap dump (was dump heap). Taking a heap dump under load will cause transaction/call failures.

jConsole should work too, but it can be service impacting.

But, since this is the only way I have to get hold of you.....

Your CE1 node needs to be rebuilt. We've noticed that file permissions have been changed in several places and suspect that's what may be going on here. Until we can get that done, please use your CE2 node instead.

You'll get service more quickly if you go through the normal Collaboratory service procedure (i.e. email to collaboratory@avaya.com). We just heard that you were having problems through another means, and so consulted this forum.

Is it possible to connect via the JTAPI from a PC which is connected through the VPN to the Collaboratory Lab to create calls, answer calls, etc?

Yes. If you VPN in you are given access to the AES and can configure it so that your PC is a client.


Is it possible to connect via the JTAPI from an EDP-SnapIn installed on the Collaboratory Lab?

Yes.


Any examples?

EDP 3.1 SDK has no sample apps that do this, but there are many Java samples under the JTAPI section of AES. Those would have to be converted to snap-ins (essentially J2EE applications) to run in EDP.

ECC comes pre-installed in Collaboratory 3.1 and should be available in our around early November '15.

The problem is fixed. Sorry for the inconvenience.

This forum is not normally monitored by the Collaboratory support team. In the future, please just send email to "collaboratory@avaya.com".